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Abstract 


In this paper, we present a formal model of the reliable multicast service that ensures eventual 
packet delivery with, possibly, some timeliness guarantees. This model dictates precisely what it 
means to be a member of the reliable multicast group and which packets are guaranteed delivery 
to which members of the group. Moreover, it is reasonable, implementable, and broad; that is, 
it captures the intended behavior of a large collection of reliable multicast protocols. We also 
present a formal model of the Scalable Reliable Multicast (SRM) protocol [1]. We show that 
our model of SRM is safe, in the sense that it is a faithful implementation of our model of the 
reliable multicast service; that is, it may only deliver appropriate packets to each member of 
the reliable multicast group. We also show that, under certain constraints, the implementation 
is live, in the sense that it guarantees the timely delivery of the appropriate packets to the 
appropriate members of the reliable multicast group. 


1 Introduction 


With the increasing use of the Internet, multi-party communication and collaboration applications 
are becoming mainstream. Reliable multicast is a communication service that facilitates such 
applications. In the recent past, a slew of protocols have been proposed to reliably multicast 
packets efficiently [1-4, 7,8]. However, reliability in the multicast setting has assumed many 
meanings, ranging from in-order eventual delivery to timely delivery where a small percentage 
of packet losses is tolerable. The many notions of reliability stem from the varying assumptions 
regarding the communication environment and the goals and requirements of the applications to 
which particular reliable multicast protocols cater. 


Most often, the behavior of reliable multicast protocols is described informally. To our surprise, 
a protocol’s description is seldom accompanied by a precise definition of its reliability guarantees. 
In its simplest form, reliability is informally defined as the eventual delivery of all multicast 
packets to all group members; other notions of reliability include ordering, no-duplication, and 
timeliness guarantees. Although intuitive, this simplistic reliability definition does not precisely 
specify which packets are guaranteed delivery to which members of the group, especially when the 
group membership is dynamic. Moreover, protocol descriptions put little emphasis on the behavior, 
or the analysis of the behavior, of the protocol when the group membership is dynamic, either due 
to failures or frequent joins and leaves. As hosts become more mobile, a better understanding 
of the behavior of such services and protocols in the context of a dynamic group membership is 
increasingly important. 


In this paper, we present a formal model of the reliable multicast service, which we henceforth 
refer to as the reliable multicast specification (RMS). Specifying the reliable multicast service is 


not straightforward. The plethora of reliable multicast protocols cater to diverse applications that 
impose diverse correctness and performance requirements. Clearly, capturing the functionality of all 
reliable multicast protocols using a single specification would be quite complex and unwieldy. Our 
reliable multicast service specification formalizes the behavior of a number of protocols, such as 
SRM [1] and LMS [7], that strive to provide eventual delivery with, possibly, some timeliness 
guarantees. We stipulate that, in the context of dynamic group membership, membership is 
intrinsically intertwined with reliability; that is, membership and reliability must be addressed 
together. Thus, our specification dictates precisely what it means to be a member of a reliable 
multicast group and which packets are guaranteed delivery to which members of the reliable 
multicast group. We parameterize our specification with a delivery latency bound, which specifies 
an upper bound on the latency incurred to reliably deliver multicast packets. This parameterization 
results in a reliable multicast service specification that encompasses the behavior of a collection 
of reliable multicast protocols, some with loose and others with potentially stringent timeliness 
guarantees. 


We also present a formal model of the Scalable Reliable Multicast (SRM) protocol [1]. Our model 
of SRM, which we henceforth refer to as the reliable multicast implementation (RMI), involves 
several components with distinct functionalities, such as the maintenance of the reliable multicast 
group membership and the packet loss recovery. This decomposition simplifies the reasoning and 
facilitates future modifications to the implementation. We show that RMI is safe, in the sense that 
it is a faithful implementation of RMS; that is, it may only deliver appropriate packets to each 
member of the reliable multicast group. We also show that, under certain constraints, RMI is live, 
in the sense that it guarantees the timely delivery of the appropriate packets to the appropriate 
members of the group. 


The rest of the paper is organized as follows. Section 2 presents our modeling framework. Section 3 
presents the abstract view of the physical system that we adopt in our work. Section 4 presents 
RMS and its eventual and timely reliability properties. Section 5 presents RMI, derives constraints 
on RMI’s packet loss recovery parameters, and analyzes RMI’s safety and liveness with respect to 
RMS. Finally, Section 6 presents the paper’s contributions and future work directions. 


2 Modeling Framework and Notation 


In this paper, we use the timed input/output (I/O) automaton (TIOA) modeling framework 
(introduced as the general timed automaton model in Ref. 6); a framework for modeling timed 
systems. A timed I/O automaton A is a state-machine in which transitions are labeled by actions. 
A’s actions (acts(A)) are partitioned into input (in(A)), output (out(A)), internal (int(A)), and 
time-passage sets. Time-passage actions model the passage of time. The input and output actions 
of A are collectively referred to as external; denoted ext(A). Input, output, and time-passage 
actions are collectively referred to as visible; denoted vis(A). A timed I/O automaton A is 
defined by its signature (input, output, internal, and time-passage actions), states (states(A)), 
start states (start(A)), and state-transition relation (trans(A)). The state-transition relation of 
A is a cross product of states, actions, and states that dictates A’s allowable transitions; that is, 
trans(A) C states(A) x acts(A) x states(A) and a transition of A from s to s’ through action 7 is 
denoted by the tuple (s, 7, 5’). 


A timed execution fragment a of A is a finite or infinite alternating sequence, @ = $971517282..., 
of states and actions consistent with A’s state-transition relation; that is, s, € states(A), 
Tr+1 € acts(A), and (sx, 741, $k41) € trans(A), for all k € N. For any two timed execution 
fragments a and a’ of A, we use the notation a < a’ to denote that a is a prefix of a’. A timed 
execution fragment of A is admissible if an infinite amount of time elapses within the particular 
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fragment. An admissible timed execution fragment a of A is fair when no action is enabled in 
every state of a suffix of a without appearing in the given suffix. The time of occurrence of an 
action 7, for k € Nt, within a timed execution fragment a of A is the time elapsing within a prior 
to the occurrence of mz. Letting s,s’ € states(A) be any two states occurring in a timed execution 
fragment a of A, we use the notation s <q s’ (s <q s’) to denote that the particular occurrence of 
s appears no later than (prior to, respectively) the particular occurrence of s’ in a. 


The timed trace (@ of a timed execution fragment a of A is the sequence of visible actions in a, each 
paired with its time of occurrence. For any two timed traces 3 and 3’ of A, we use the notation 
3 < ' to denote that ( is a prefix of 3’. 


A timed execution of A is a timed execution fragment of A that begins in one of A’s start states. 
We let aerecs(A) denote the set of all admissible timed executions of A, attraces(A) denote the 
timed traces of all executions in aexecs(A), fair-aexecs(A) denote the set of all fair admissible timed 
executions of A, and fair-attraces(A) denote the timed traces of all executions in fair-aexecs(A). 


Two timed I/O automata A; and A2 are compatible if int(A;)Nacts(A;) = @ and out(A;)Nout(A;) = 
0, for i,7 € {1,2},2 4 7. The composition of compatible timed I/O automata yields a timed I/O 
automaton. The hiding operation reclassifies output actions of a timed I/O automaton as internal. 
Letting A,B be timed I/O automata with the same external interface, B implements A, denoted 
B < A, when its external behavior is allowed by A; that is, when attraces(B) C attraces(A). 
The implementation relation among two timed I/O automata is often shown by defining a timed 
simulation relation; that is, relating states of B to states of A and showing that for any step of B 
there is a timed execution fragment of A with the same timed trace as the step of B that preserves 
the state relation. 


We use a precondition-effect style notation to define the state-transition relations of timed I/O 
automata. Moreover, we use the notation S;U= S2, S;\= So, and s :€ S as shorthand for 
Sy := $1, U So, S$) := $1\ So, and the assignment of an arbitrary element of S to the variable s. 


3 The Physical System 


We assume that the physical system is comprised of an infinite set of hosts that interact through an 
underlying network. This network involves a set of interconnected routers. Each host is connected 
to a particular router of the underlying network; for each host, we refer to this particular router 
as the gateway router of the particular host. Hosts and routers are connected among themselves 
through bi-directional communication links. 


We assume that all hosts are of comparable processing power and storage resources. Resident 
on each host are a set of processes. We assume that hosts are symmetric in the sense that the 
same set of processes reside on each host. The set of processes on each host consists of a single 
application process and several additional communication service processes. Henceforth, we refer 
to the application process at each host as the client at the given host. The communication service 
processes, either individually or collectively, provide the communication services required by the 
client. For instance, the IP unicast service may be modeled as a set of processes, one such process 
for each host. Clients may thus exchange IP unicast packets through their respective IP unicast 
processes; these may in turn interact with the hosts’ gateway routers. 


In terms of system faults, we consider only host crashes and packet drops on the communication 
links. Once a host crashes it remains crashed thereafter. A host is said to be operational prior to 
crashing and to have crashed thereafter. All the processes on each host are fate-sharing; that is, if 
a host crashes, then all of its processes crash. Router failures and network partitions are assumed 
to be ephemeral. Such failures are modeled as numerous consecutive packet drops. 
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Figure 1 Reliable Multicast Specification Component Interaction 
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Since crashes are assumed to be permanent, we model host restarts implicitly. We think of the 
restarting of a host as its reincarnation as a completely new host; that is, after crashing, a host 
may assume the identity of another host that has up to that point in time been idle. This modeling 
simplification is equivalent to explicitly modeling host restarts and having hosts choose a unique 
host identifier each time they restart. Such an identifier could involve, for instance, the processor 
identifier and an infinite reincarnation counter that is stable across crashes. 


4 Reliable Multicast Specification (RMS) 


We abstractly model the reliable multicast service as a single component that interacts with all 
client processes. Thus, the reliable multicast service encapsulates the behavior of all communication 
service processes at all hosts and the underlying network. For simplicity, we assume that there is 
a single reliable multicast group. Since we assume a single client per host and a single reliable 
multicast group, we do not distinguish among the client process and the host when considering 
reliable multicast group membership. In fact, we often use the terms client and host interchangeably. 


Throughout our treatment of reliable multicast, we adopt the packet naming scheme used by 
Floyd et al. [1]. In this scheme, clients (applications) assign unique sequence numbers to each 
packet they multicast. These sequence numbers are assigned in a continuous fashion as hosts join, 
leave, and rejoin the reliable multicast group; that is, consecutive packets sent by each host are 
assigned consecutive sequence numbers. Thus, packets are uniquely and persistently identified by 
a pair involving their source host and their sequence number. Since the clients (applications) are 
responsible for naming packets, packets are referred to as application data units (ADUs). 


4.1 Formal Model 


We formally specify the reliable multicast service and each of the client processes using timed I/O 
automata. The automaton RM(A), for A € R=° U oo, models the reliable multicast service. 
RM(A) defines what it means to be a member of the reliable multicast group and specifies 
precisely which packets are guaranteed delivery to each member of the reliable multicast group. 
The parameter A specifies an upper bound on the amount of time required by the reliable multicast 
service to reliably deliver each packet. The automaton RM-CLIENT, models the client at the host 
h. We let RM-CLIENTS denote the composition of all client automata and RMs(A), for any 
A € R2°Uoo, denote the composition of the reliable multicast service and all client automata; 
that is, RMs(A) = RM(A) x RM-CulentTs. Figure 1 depicts the interaction of the RM(A) and 
RM-CLIENTa, for h € H, automata. 


We proceed by presenting some preliminary definitions and, subsequently, defining the RM(A) and 
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Figure 2 Reliable Multicast Specification Definitions 
HAT Set of all hosts. 


Status = {idle, joining, leaving, member, crashed} 


Prue-curnt = Set of packets such that V p © Praw-curnr 
source(p) € H 
seqno(p) EN 
data(p) € {0, 1}* 
id(p) € H x N: id(p) = (source(p), seqno(p)) 
suffiz(p) = {(s,t) € H x N | source(p) = s A seqno(p) < 1} 


RM-CLIENT;), automata. 


4.1.1 Preliminary Definitions 


Figure 2 includes several set definitions pertaining to our reliable multicast service specification. 
A is the set of all hosts that could potentially participate in the reliable multicast communication. 


The set Status consists of all possible valuations of the reliable multicast membership status of a 
host. The value idle indicates that the host is idle with respect to the reliable multicast group; 
that is, it is neither a member, nor in the process of joining or leaving the reliable multicast 
group. The value joining indicates that the host is in the process of joining the reliable multicast 
group; that is, the client has issued a request to join the reliable multicast group and is awaiting 
an acknowledgment of this join request from the reliable multicast service. The value leaving 
indicates that the client is in the process of leaving the reliable multicast group; that is, the client 
has issued a request to leave the reliable multicast group and is awaiting an acknowledgment of 
this leave request from the reliable multicast service. The value member indicates that the client is 
a member of the reliable multicast group. The value crashed indicates that the host has crashed. 


The set Prm-curenr represents the set of packets that may be transmitted by the client processes 
using the reliable multicast service. According to the ADU naming scheme described above, data 
segments are identified by their original source and a sequence number. Thus, for any packet 
p € Pro-curnr the operations source(p), seqno(p), and data(p) extract the source, sequence 
number, and data segment corresponding to the packet p. The operation id(p) extracts the source 
and sequence number pair corresponding to the packet p. Such pairs comprise unique packet 
identifiers. We also define the suffir(p) to be the subset of Pry-curnr comprised of all packets 
whose source is that of p and whose sequence number is greater than or equal to that of p. 


4.1.2 The RM(A) Automaton 


Figure 3 presents the signature, the variables, and the discrete transitions of RM(A). The RM(A) 
automaton maintains the set of members of the reliable multicast group. Hosts initiate the process 
of joining and leaving the reliable multicast group by issuing join and leave requests to the reliable 
multicast service. A request to join the reliable multicast group is effective only when the host is 
idle with respect to the reliable multicast group; that is, it is operational and neither a member of 
nor in the process of joining or leaving the reliable multicast group. A host becomes a member of 
the reliable multicast group upon the acknowledgment of an earlier join request. Hosts may only 
send and receive packets through the reliable multicast service while they are both operational and 
members of the reliable multicast group. Once a host issues a request to leave the reliable multicast 
group, it ceases to be a member of the reliable multicast group and, thus, relinquishes its right to 
receive any more reliable multicast packets. Leave requests overrule join requests in the sense that 
if the client is already in the process of joining the group while it issues a leave request, then the 
process of joining is aborted and the process of leaving is initiated. Once a host leaves the reliable 


5 


multicast group, it may later rejoin the reliable multicast group by re-issuing a join request. Hosts 
may crash at any point in time. Once a host has crashed, the reliable multicast service ignores all 
events pertaining to the crashed host. Recall that host restarts are treated implicitly by thinking 
of host restarts as host reincarnations. 


We say that a member / of the reliable multicast group has delivered the packet p if it has either 
sent or received the packet p. We say that a member h of the reliable multicast group is aware 
of a packet p, or is expecting p, if it has delivered either p or an earlier packet p’ from the source 
of p. Moreover, we say that a packet p is active if at least one member of the reliable multicast 
group that has become aware of p since last joining the reliable multicast group, has also delivered 
it since last joining the reliable multicast group. 


Once a host joins the reliable multicast group, the issue of catching up on any of the packets 
multicast earlier is orthogonal to the transmission of future packets using the reliable multicast 
service. Thus, once a host joins the reliable multicast group, the first packet it receives from 
a particular source dictates the set of packets that are guaranteed delivery to the given host. In 
particular, none of the earlier packets and any of the later packets that remain active after being sent 
are guaranteed delivery, provided the host remains a member of the reliable multicast group. The 
host may catch up on earlier packets from the given source through a separate service. For example, 
earlier packets may be requested directly from the source through a unicast communication channel. 
The rationale behind this modeling choice is that the recovery of a large number of earlier packets 
may strain the reliable multicast service and wastefully expose the recovery of earlier packets to all 
or a subset of the reliable multicast group. 


If A = oo, then RM(A) guarantees that if a packet p remains active forever after its transmission 
then any member that becomes aware of p and remains a member of the reliable multicast group 
thereafter, delivers p. Equivalently, if two members become aware of a packet p, remain members 
forever thereafter, and one member delivers p, then the other member delivers p also. It is important 
to note that a host is not required to remain a member of the reliable multicast group indefinitely in 
order for the packets it multicasts to be received by hosts that become aware of them; the eventual 
reception of packets is guaranteed to all hosts that become aware of them provided the packets 
remain active forever after they are sent. 


If A € R@°, then RM(A) guarantees that if a packet remains active for A time units past its 
transmission, then it is delivered to all hosts that become aware of it within these A time units 
and, subsequently, remain members of the reliable multicast group for the remaining duration of 
these A time units elapse. 


Parameters The RM automaton is parameterized by a time bound, A € R° U {oo}, which 
specifies the maximum delay in delivering each packet sent to the appropriate members of the 
reliable multicast group. The value co corresponds to the case in which the reliable multicast 
service guarantees the eventual delivery of all packets to the appropriate members of the reliable 
multicast group. An instance of the RM automaton is denoted by RM(A). 


Variables The variable now € R2° denotes the time that has elapsed since the beginning of an 
execution of RM. Each variable status(h) € Status, for h € H, denotes the status of the host h. 
Each of its valuations is described in the definition of the set Status. We say that the host h is 
operational if it has not crashed. After a host h crashes, none of the input actions pertaining to h 
affect the state of RM and none of the locally controlled actions pertaining to h are enabled. 


Each variable trans-time(p) € R=° U L, for p € Pro-cusnr, denotes the transmission time of 
the packet p; that is, the time the packet p was sent by its source. Prior to the transmission of p, 


Figure 3 The RM(A) Automaton 


Parameters: 


A € R2°U {oo} 


Actions: 


Input: 
crash; for h € H 
rm-join,, for h € H 
rm-leave;,,, for hh € H 
rm-send;,(p), for h € H,p € Pru-curnr 


Output: 
rm-join-ack,, for h © H 
rm-leave-ack,, for h € H 
rm-recv;,(p), for h € H,p € Pru-curnr 
Time Passage: 


v(t), for t € R2° 


Variables: 


now € R2°, initially now = 0 

status(h) € Status, for all h € H, initially status(h) = idle, for allh € H 

trans-time(p) € R2° U L, for all p € Pam-curnr, initially trans-time(p) =L, for all p € Pru-cuenr 
expected(h,h') C H xN, for all h,h’ € H, initially expected(h, h’) = 9, for all h,h’ € H 
delivered(h, h’) C H XN, for all h,h’ € H, initially delivered(h, h’) = 9, for all h,h’ € H 


Derived Variables: 


idle = {h € H | status(h) = idle} 

joining = {h € H | status(h) = joining} 

leaving = {h € H | status(h) = leaving} 

members = {h € H | status(h) = member} 

intended(p) = {h € H | id(p) € expected(h, source(p))}, for all p € Pam-curnr 
completed(p) = {h € H | id(p) € delivered(h, source(p))}, for all p € Pam-cusnr 
sent-pkts = {p © Prm-cumnr | trans-time(p) AL} 

active-pkts = {p € Pry-curnr | p € sent-pkts A intended(p) N completed(p) 4 0} 


Discrete Transitions: 


input crash; output rm-join-acky, 
eff status(h) := crashed pre h € joining 
foreach h’ € H do: eff status(h) := member 


expected(h,h’) :=0 


tput rm-1 -ack 
delivered(h, h’) :=0 ct eeen CG aie Sie nate 


‘ = pre h € leaving 
input rm—joiny, eff status(h) := idle 
eff if h € idle then 


tput rm- 
status(h) := joining CueputmmareerP) 


pre h € members\{source(p) } 


input rm-leave;, Ap € sent-pkts 


eff if h € joining U members then A(expected(h, source(p)) = 0 
status(h) := leaving => now < trans-time(p) + A) 
foreach h’ € H do: A(expected(h, source(p)) #0 

expected(h,h') :=0 => id(p) € expected(h, source(p))) 
delivered(h,h’) :=90 eff if expected(h, source(p)) = @ then 


expected(h, source(p)) := suffix(p) 


i crn d 
POPE ea ssend (2) delivered(h, source(p)) U= {id(p)} 


eff if h © members {source(p)} then 


if expected(h,h) =@ then time-passage v(t) 
expected(h, h) := suffix (p) pre V p € active-pkts, 

if id(p) € expected(h, h) then now +t < trans-time(p) + A 
trans-time(p) := now Vintended(p) C completed (p) 
delivered(h, h) U= {id(p)} eff now := now +t 


trans-time(p) is equal to L. Each variable expected(h, h’) C HxN, for h, h’ € H, is the set comprised 
of the identifiers of the packets from h’ that the host h is aware of since it last joined the reliable 
multicast group and, consequently, expects to deliver. Each variable delivered(h,h’) C H x N, for 
h,h' € H, is the set comprised of the identifiers of the packets from h’ that the host h has delivered. 


Derived Variables The derived variable idle C H is a set of hosts that is comprised of all the 
hosts that are idle with respect to the reliable multicast group. The derived variable joining C H 
is a set of hosts that are in the process of joining the reliable multicast group. The derived variable 
leaving C H is a set of hosts that are in the process of leaving the reliable multicast group. The 
derived variable members C H is a set of hosts that are members of the reliable multicast group. 
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The derived variable intended(p), for each p € Pry-curnr; is the set of hosts that are expecting 
the delivery of the packet p. We henceforth refer to the set intended(p) as the intended delivery 
set of p. The derived variable completed(p), for each p € PrM-cumnt, is the set of hosts that have 
delivered the packet p. Recall that we say that a host has delivered a packet p if it has either 
sent or received p. We henceforth refer to the set completed(p) as the completed delivery set of p. 
The derived variable sent-pkts is the set of packets that have been sent since the beginning of the 
given execution of the RM(A) automaton. The derived variable active-pkts is the set comprised of 
the sent packets that have been delivered by at least one of the hosts in their respective intended 
delivery sets. 


Input Actions Each input action crashp,, for h € H, models the crashing of the host h. The 
effects of crash, are to record that the host h has crashed by setting the variable status(h) to 
the value crashed. Furthermore, the crash, action resets the set of packets that the host h is 
expecting from each source and the set of packets it has delivered from each source. Thus, the RM 
automaton is released of the obligation to deliver any of the active packets to the host h. 


The input action rm-join, models the client’s request at the host h to join the reliable multicast 
group. The rm-join, action is effective only while the host h is idle with respect to the reliable 
multicast group. When effective, the rm-join, action sets the status(h) variable to joining so 
as to record that the host fh has initiated the process of joining the reliable multicast group. If 
the client is either a member of or in the process of joining the reliable multicast group, then the 
rm-joiny action is superfluous. If the client is already in the process of leaving the group, then the 
rm-join, action is discarded so as to allow the process of leaving the reliable multicast group to 
complete. 


The input action rm-leave;, models the client’s request at the host h to leave the reliable multicast 
group. The rm-leave, action is effective only while the host h is a member of or in the process 
of joining the reliable multicast group. When effective, the rm-leave,, action sets the status(h) 
variable to leaving so as to record that the host h has initiated the process of leaving the reliable 
multicast group. Moreover, the rm-leave, action initializes the set of packets that the host h is 
expecting from each source and the set of packets it has delivered from each source. Thus, the RM 
automaton is released of the obligation to deliver any of the active packets to the host h. Leave 
requests overrule join requests; that is, when a rm-leavey,, action is performed while the host h is in 
the process of joining the reliable multicast group, its effects are to abort the process of joining and 
to initiate the process of leaving the reliable multicast group. If the client is either idle or already 
in the process of leaving the reliable multicast group, then the rm-leave,, action is superfluous. 


The client at h sends the packet p using the reliable multicast service through the input action 
rm-send;,(p). The rm-send;(p) action is effective only when the host h is both a member of the 
reliable multicast group and the source of the packet p. If p is the first packet sent by the host h, 
then the rm-send;(p) action initializes the set of packets expected by h from h to the set suffix(p); 
that is, all packets whose source is h and whose sequence number is greater or equal to that of p. 
Then, if p is in the expected set of packets of h from h, the rm-send,(p) records the transmission 
time of p by setting the variable trans-time(p) to now and adds the packet p to the set of packets 
from the host h that the host h has delivered. 


Output Actions The output action rm-join-acky, acknowledges the join request of the client 
at h. The action rm-join-ack,, is enabled when the host h is in the process of joining the reliable 
multicast group. Its effects are to set the status(h) variable to member so as to indicate that the 
client at h has become a member of the reliable multicast group. 


The output action rm-leave-acky;, acknowledges the leave request of the client at h. The action 
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rm-leave-ack,, is enabled when the host h is in the process of leaving the reliable multicast group. 
Its effects are to set the status(h) variable to idle so as to indicate that the client at h has become 
idle with respect to the reliable multicast group. 


The output action rm-recv,(p) models the delivery of the packet p to the client at h. The 
rm-recvp(p) action is enabled when the host h is a member of the reliable multicast group, the 
host A is not the source of p, and p is an active packet. Moreover, if the expected deliver set of h 
with respect to the source of p is undefined, then the delivery deadline trans-time(p) + A of p must 
not have expired; that is, the first packet from any source to be delivered to any client must be 
delivered prior to its delivery deadline. If the expected deliver set of h with respect to the source 
of p has already been defined, then p must be expected by h. The effects of the rm-recvp(p) action 
are: i) to define the expected delivery set of h with respect to the source of p to the set suffix(p), 
unless already defined, and ii) to add the host h to the completed delivery set of p. 


Time Passage The action v(t) models the passage of t time units. Time is prevented from 
elapsing past the delivery deadline of any active packet that has yet to be delivered to all the hosts 
in its intended delivery set. Thus, prior to allowing time to elapse past the delivery deadline of an 
active packet, all the hosts in its intended delivery set must either send or receive the packet, leave 
the reliable multicast group, or crash. 


4.1.8 The RM-CLIENT;, Automata 


Figure 4 presents the signature, the variables, and the discrete transitions of RM-CLIENT,;,. The 
RM-CLIENT, automaton models a well-behaved client; that is, a client that: i) transmits packets 
only when it is a member of the reliable multicast group, ii) transmits packets in ascending and 
contiguous sequence number order, iii) issues join requests only when it is idle with respect to the 
reliable multicast group, and iv) issues leave requests only when it is a member of the reliable 
multicast group. 


Variables The variable now € R2° denotes the time that has elapsed since the beginning of an 
execution of RM-CLIENT,. The variable status € Status denotes the membership status of the 
host h. It takes on one of the following values: idle, joining, leaving, member, and crashed. 
These values indicate whether the host h either is idle, joining, leaving, a member of the reliable 
multicast group, or has crashed, respectively. We say that a host h is operational if it has not 
crashed. After a host h crashes, none of the input actions affect the state of RM-CLIENT;, and 
none of the locally controlled actions, except the time passage action, are enabled. The variable 
seqno € N U L indicates the sequence number of the last packet to have been transmitted by 
RM-CLIENT;, — the value | indicates that RM-CLIENT, has yet to transmit a packet using the 
reliable multicast service. The segno variable is initialized to L. 


Input Actions The input action crash; models the crashing of the host h. The effects of crash; 
are to record that the host h has crashed by setting the status variable to crashed. 


The input action rm-join-ack;, acknowledges the client’s join request at h. If the client is in the 
process of joining the reliable multicast group, i.e., status = joining, then the rm-join-acky,, 
action sets the status variable to member so as to indicate that the client at h has become a member 
of the reliable multicast group. 


The input action rm-leave-ack; acknowledges the client’s leave request at h. If the client is in 
the process of leaving the reliable multicast group, i.e., status = leaving, then the rm-leave-acky;, 


Figure 4 The RM-CLIENT;, Automaton 


Parameters: 
heH 
Actions: 
Input: Output: 
crash, rm-joinp, 


rm-join-ackp, 
rm-leave-ackp, 
rm-recv),(p), for all p € PaM-cuent 


rm-leavep, 

rm-send), (p), for all p € Pra-cunt 
Time Passage: 

v(t), for t € R2° 


Variables: 


now € R2°, initially now = 0 
status € Status, initially status = idle 
seqno EN UL, initially seqno =L 


Discrete Transitions: 


input crash; 

eff status := crashed 

input rm-join-ackp, 

eff if status = joining then 
status := member 

input rm-leave-ack;, 


eff if status = leaving then 
status := idle 


output rm-join;, 
pre status = idle 

eff status := joining 
output rm-leave, 


pre status = member 
eff status := leaving 


output rm-send,, (p) 


pre status = member / source(p) = h 


A(segno = Vseqno(p) = segno + 1) 


input rm-recvp(p) Bit wegne seine) 


eff None 
time-passage v(t) 


pre None 
eff now :=now+t 


action sets the status variable to idle so as to indicate that the client at h has become idle with 
respect to the reliable multicast group. 


The input action rm-recv,(p) models the delivery of the packet p to the client at h. This action 
has no effects. 


Output Actions The output action rm-joiny, is performed by the client to initiate the process 
of joining the reliable multicast group. This action is enabled only while the client is idle with 
respect to the reliable multicast group. Its effects are to set the status variable to joining so as 
to indicate that the client at h has initiated the process of joining the reliable multicast group. 


The output action rm-leave,, is performed by the client so as to initiate the process of leaving the 
reliable multicast group. This action is enabled only while the client is a member of the reliable 
multicast group. Thus, the client waits for join requests to complete prior to issuing leave requests. 
Its effects are to set the status variable to leaving so as to indicate that the client at h has initiated 
the process of leaving the reliable multicast group. 


The output action rm-send,;(p) models the client’s transmission of the packet p using the reliable 
multicast service. The rm-send;(p) action is enabled when the client is a member of the reliable 
multicast group and the packet p is either the first or the next packet in the sequence of packets 
to be transmitted by the client at h; that is, status = member, source(p) = h, and either seqno =L 
or segno(p) = seqno+ 1. The effects of the rm-send,(p) action are to set segno to segno(p) (or, 
equivalently, to increment seqno), thus recording the transmission of the packet p. 


Time Passage The action v(t) models the passage of t time units. It is enabled at any point in 
time and increments the variable now by ¢ time units. 
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4.2 Preliminary Properties and Definitions 


The automaton RM-CLIENT,, for any h € H, satisfies transmission correctness, transmission 
uniqueness, and in order transmission. Transmission correctness is the property that clients only 
transmit packets for which they are actually the source. Transmission uniqueness is the property 
that no two packets transmitted by a client share the same identifier. Finally, in order transmission 
is the property that each client transmits packets through the reliable multicast group in ascending 
sequence number order. 


Lemma 4.1 (Transmission Correctness) Let 3 be any timed trace of RM-CLIENT;),, for any 
h € H. If B contains the action rm-send,(p), for some p © Pru-cuent, then the host h is the 
source of p; that is, h = source(p). 


Proof: Follows directly from the precondition of the action rm-send;(p). a 


Lemma 4.2 (Transmission Uniqueness) Let 3 be any timed trace of RM-CLIENTh,, for any 
h € H. For any packet identifier (s,1) € H x N, at most one packet p © Pau-cuntr ts transmitted 
within 3; that is, 8 contains at most one action rm-sendp(p), for p © Prw-cumnr, such that 


id(p) = (s,%). 


Proof: Let a be any timed execution of RM-CLIENT, such that 3 = ttrace(a). Within a each 
action rm-send;(p’), for p’ € Prm-cunnr such that source(p’) = h, transmits the packet p’ whose 
sequence number is equal to segno and increments the variable seqno. Since no other actions affect 
the variable seqno it follows that seqno monotonically increases each time a packet is transmitted. 
Thus, @ does not contain the transmission of more than one packets sharing the same sequence 
number. | 


Lemma 4.3 (In Order Transmission) Let 3 be any timed trace of RM-CLIENT;, for h € H, 
that contains the actions rm-send;,(p) and rm-send;(p’), for p,p’ © Pra-cumnt, such that h = 
source(p) = source(p') and seqno(p) < segno(p’). Then, the action rm-send;(p) precedes the 
action rm-sendp(p’) in 3. 


Proof: The effects of any rm-send;(p”), for p” € Pro-cuenr, are to increment the variable 
RM-CLIENT,.segno. Moreover, no other action affects the variable RM-CLIENT),.seqno. Thus is, 
the variable RM-CLIENT),.seqno is monotonically non-decreasing in any execution of RM-CLIENT». 


The actions rm-send;,(p) and rm-send,(p’) are enabled only when segno(p) = RM-CLIENT).seqno 


and segno(p’) = RM-CLIENT).seqno, respectively. It follows that rm-send;(p) precedes the action 
rm-send,(p’) in any timed execution of RM-CLIENT, such that 6 = ttrace(a). a 


The automaton RMs(A), for any A € R=° U ov satisfies transmission integrity. Transmission 
integrity it the property that, within a timed trace of RMs5(A), the reception of a packet must be 
preceded by the particular packet’s transmission. 


Lemma 4.4 (Transmission Integrity) Let 3 be any timed trace of RMs(A), for any A € 
R=°Uoco. For h,h’ € H and p € Pru-curnnr, such that h # h’ and h = source(p), it is the 
case that any rm-recvp/(p) action is preceded in 3 by a rm-sendp(p) action. 


Proof: Let a be any timed execution of RMg(A) such that @ = ttrace(a). It suffices to show 
that any rm-recvy),(p) action is preceded by a rm-send;(p) action within a. This follows directly 
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from the precondition of the action rm-recv,,/(p). In particular, the precondition of the action 
rm-recvp/(p) requires that there is a tuple in pkts corresponding to the packet p. However, such a 
tuple may be added to pkts only by the occurrence of the action rm-send;,(p). Thus, the occurrence 
of any action rm-recv),(p) within a is preceded by the occurrence of the action rm-send;(p). 1 


We proceed by defining the set of members of the reliable multicast group following a finite timed 
trace of RMs(A). 


Definition 4.1 (Membership) Let 3 be any timed trace of RMs(A), for any A € R=° Uoo. 
We define the members of 3, denoted members(3), to be the set of all hosts h © H such that 3 
contains a rm-join-ack, action that is not succeeded by either an rm-leave,;, or a crash, action. 
If a host h € H is in the set members(3), then we say that h is a reliable multicast group member 


of @. 


The following lemma relates the set members(() of Definition 4.1 to the derived variable members 
of the automaton RM. 


Lemma 4.5 Let A € R=° Uoo and a be any finite timed execution of RMgs(A). Letting s be the 
last state in a and (3 be the timed trace of a, it is the case that s.members = members((3). 


Proof: Follows directly from the definitions of s.members and members({3). a 


Lemma 4.6 Let A € R29 Uoo, h € H, and a be any timed execution of RMs(A) such that 
h € members(ttrace(a)). Letting s be any state following the last occurrence of the rm-join-ackp, 
action in a, it is the case that h € s.members. 


Proof: Let a’,a” be the execution fragments of RMgs(A) such that a/a”’ = a and the last action 
in a’ is the last occurrence of the rm-join-ack,, action in a. Letting s’ = a’.Istate, the effects of the 
rm-join-ack;,, action imply that s’.status(h) = member. By the definition of members(ttrace(a)), 
it follows that a” contains neither a rm-leave,, or a crashy, action. 


The rest of the proof involves showing that for any prefix a, of a” of length n € N, such that 
Sn = An.lstate, it is the case that h € s,.members. This follows by a simple induction on the length 
n of Qn. For the base case, consider ag. Since ag = s’ and s’.status(h) = member, it follows that 
sq.status(h) = member, as required. For the inductive step, consider ax41. Let 5441 = ap41.lstate, 
let a, be the prefix of a,41 involving its first k steps, and s, = ax.lstate. The induction hypothesis 
is the assertion that s;.status(h) = member. Since a” contains neither a rm-leavey,, or a crashp 
action, the k + l-st step of a, is neither an rm-leave, or a crash; action. Moreover, since 


s,.status(h) = member, the k + 1-st step of ax41 is neither an rm-join,, rm-join-ackp, nor 
rm-leave-ack, action. The remaining actions do not affect the status(h) variable. Thus, it follows 
that s,41.status(h) = member, as required. a 


We proceed by defining the intended and completed delivery sets of a packet within a timed trace 
of RMs5(A). 


Definition 4.2 (Intended Delivery Set) Let 3 be any timed trace of RMs(A), for any A € 
R=°Uoo, containing the transmission of a packet p € Prw-cumnr. We define the intended delivery 
set of p within 3, denoted intended(p, 3), to be the members of 3 that have delivered either the 
packet p or an earlier packet from the source of p since they last joined the reliable multicast group; 
that is, h € intended(p, 3) if and only if h © members(3) and the last rm-join-ack,, action in 3 
is succeeded by either a rm-send;(p') or a rm-recvp(p') action, where source(p') = source(p) and 
seqno(p’) < seqno(p). 
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Lemma 4.7 Let 3 be any finite timed trace of RMg(A), for any A € R2° Uo, containing the 
transmission of a packet p € Pro-cusnr. Then, it is the case that intended(p, 3) C members((3). 


Proof: Follows directly from Definition 4.2. | 


The following lemma relates the intended delivery set of a packet p within a timed trace G@ defined 
in Definition 4.2 to the derived variable intended(p) of the RM automaton. 


Lemma 4.8 Let A € R7° Uoo, p € Prom-cunnt, and a be any finite timed execution of RMs(A) 
that contains the transmission of p. Letting s = a.lstate and 3 = ttrace(a), it is the case that 
s.intended(p) = intended(p, 3). 


Proof: Follows directly from the definition of the derived variable intended(p) and Definition 4.2. 
a 


Definition 4.3 (Completed Delivery Set) Let @ be any timed trace of RMs(A), for any 
A € R2°Uo, containing the transmission of a packet p € Pry-cusnr. We define the completed 
delivery set of p within 2, denoted completed(p, 3), to be the members of 3 that have delivered 
the packet p since they last joined the reliable multicast group; that is, h € completed(p, 3) if and 
only if h © members(3) and the last rm-join-ackp, action in G is succeeded by either a rm-sendp(p) 
or a rm-recvp(p) action. 


The following lemma relates the completed delivery set of a packet p within a timed trace (@ defined 
in Definition 4.3 to the derived variable completed(p) of the RM automaton. 


Lemma 4.9 Let A € R29 Uo, p € Pro-curntr, and a be any finite timed execution of 
RM(A) x RMCLIENTS that contains the transmission of p. Letting s = a.lstate and 3 = ttrace(a), 
it is the case that s.completed(p) = completed(p, (3). 


Proof: Follows directly from the definition of the derived variable completed(p) and Definition 4.3. 
a 


We continue by defining the set of active packets within a timed trace of RMg(A), for any 
A € R2° Uoo. This set is comprised of the packets whose intended and completed delivery sets 
within the given timed trace overlap; that is, the packets for which there is at least one host that 
was and has remained a member of the reliable multicast group following the packet’s transmission 
and, moreover, has either sent or received the packet. 


Definition 4.4 (Active Packets) Let 3 be any timed trace of RM(A) x RMCLIENTS, for any 
A € R*°Uco. We define the set of active packets within 3, denoted active-pkts(3), to be 
the set of all packets p € Prm-cumyr such that intended(p, 3) M completed(p, 3) #0. If a packet 
p © Pru-curnr ts in the set active-pkts(G), then we say that p is active within . 


The following lemma relates the set of active packets defined in Definition 4.4 to the derived variable 
active-pkts of the RM automaton. 


Lemma 4.10 Let A € R2° Uoo, p € Pryu-cuentr, and a be any finite timed execution of 
RM(A) x RMCLIENTS that contains the transmission of p. Letting s = a.lstate and 3 = ttrace(a), 
it is the case that s.active-pkts = active-pkts((). 
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Proof: Follows directly from Lemmas 4.8 and 4.9, Definition 4.4, and the definition of the derived 
variable active-pkts of the RM automaton. | 


Lemma 4.11 Let 3, 3’ be timed traces of RM(A) x RMCLIENTS, for any A € R2°Uoo, containing 
the transmission of a packet p € Prm-curnr such that B’ < 8. Then, it is the case that if 
p € active-pkts(3) then p € active-pkts(’). 


Proof: We prove the above claim by contradiction. Suppose that it is the case that p ¢ 
active-pkts(3’) and p € active-pkts(3). Thus, there must be some action 7 following 3’ such 
that p ¢ active-pkts(3,) and p € active-pkts(3,-7), where 3_, 3! are the trace fragments of 3 such 
that 6,-7- GL = B. 

Let a be any timed execution of RM(A) x RMCLIENTS such that 6 = ttrace(a) and s, and si 
be the pre- and post-states of 7 within a. We proceed by considering the possibility of a being 
any of the actions of the RMs(A) automaton that affect the valuation of the derived variable 
active-pkts. Since p ¢ active-pkts(G,), Lemma 4.10 implies that p ¢ s,.active-pkts. Thus, none of 
the rm-recv;,(p), for h € H, are enabled. Lemma 4.1 implies that none of the actions rm-send;(p), 
for h € H, except for h = source(p) are enabled. Moreover, since p has already been sent within 
8,, Lemma 4.2 implies that rm-send,(p), for h = source(p), is not enabled in s,. The only other 
actions that affect the variable active-pkts are the crashp, and rm-leave,, actions, for h € H. The 
effects of these actions are to remove the host h from both the intended(p) and completed(p) sets. 
Clearly, if intended(p) N completed(p) = 0 in the state s,, then the same holds for s/.. Thus, it 
follows that p ¢ s!_.active-pkts. Lemma 4.10 implies that p ¢ active-pkts(G, +7), which contradicts 
our original supposition. |_| 


Lemma 4.12 Let A € R2° Uoo, h € AH, p © Prm-curnt, and a be any timed execution of 
RMs(A) that ends with the discrete transition (s,7,s'), for 7 = rm-sendp(p). Then, it is the case 
that p € s’.sent-pkts. 


Proof: From the precondition of rm-senda(p), it follows that s.status = member and source(p) = h. 
Thus, the effects of the rm-send;,(p) are to set the variable trans-time(p) to the value of now. By the 
definition of the derived variable sent-pkts of RM(A), it follows that p € s’.sent-pkts, as required. 

| 


Lemma 4.13 Let A € R2° Uoo, p © Pro-cumnt, & € states(RM(A)) be any reachable state of 
RM(A) such that p € s.sent-pkts, and a be any timed execution fragment of RM(A) such that 
s=a.fstate. For any s’ € states(RM(A)) in a, it is the case that p € s'.sent-pkts. 


Proof: Follows from a simple induction on the length of the prefix of a leading to s’ and the fact 
that none of the actions of RM(A) reset the variable trans-time(p) to L. a 


Lemma 4.14 Let h €¢ H, p © Prm-curnt, 8 € states(RM(A)), for A € R29 Uo, and a be any 
timed execution fragment of RM(A), such that s = a.fstate, h € s.intended(p) (or, equivalently, 
id(p) € s.expected(h, source(p))), and a contains neither crash), nor rm-leave;, actions. Then, 
for any state s’ € states(RM(A)) in a, it is the case that h © s'.intended(p) (or, equivalently, 
id(p) € s’.expected(h, source(p)) ). 
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Proof: Follows from a simple induction on the length of the prefix of a leading to s’ and the 
facts that: i) the variable expected(h, source(p)) may only be set to a non-empty set if it is empty, 
and ii) the variable expected(h, source(p)) is reset to the empty set only by the actions crash; and 
rm-leavey),. |_| 


Invariant 4.1 For h € H and any reachable state s of RM(A) x RMCLIENTS, for A € R2° Uoco, 
it is the case that s|RM-CLIENTp|].status = s[RM(A)].status(h). 


Proof: Follows by a simple induction on the length of any timed execution of RM¢5(A) leading 
to s. a 


Invariant 4.2 Let h,h’ € H and s be any reachable state of RMs(A), for A € R=° U oo. 
If s|RM(A)].status(h) # member, then it is the case that s{|RM(A)].expected(h,h’) = 0 and 
s[RM(A)].delivered(h, h’) = @. 


Proof: Follows from a simple induction on the length of any execution of RMs5(A) leading 
to s and the facts that: i) the actions that set the variable RM(A).ezpected(h,h’) are only 
enabled when RM(A).status(h) = member, ii) the actions that add elements to the variable 
RM(A).delivered(h, h') are only enabled when RM(A).status(h) = member, and iii) the actions 
that reset the variables RM(A).ezrpected(h,h’) and RM(A).delivered(h,h') also set the variable 
RM(A).status(h) to a value other than member. a 


Letting A € R2° U oo, the following invariant states that, for any active packet in any reachable 
state of RM(A) x RMCLIENTS, either A time units have yet to elapse past the packet’s transmission 
time, or the packet has been delivered to all members that are aware of it. Thus, A bounds the 
delivery latency of any active packet. 


Invariant 4.3 Lets be any reachable state of the timed automaton RM¢g(A), for any A € R=°Uoo. 
Then, for any active packet p © Prm-curnt in S, t.e., p € s.active-pkts, it is the case that either 
s.now < s.trans-time(p) + A or s.intended(p) C s.completed(p). 


Proof: The proof is by induction of the number of steps n € N of a timed execution a of RM5(A) 
leading to the state s. For the base case, consider a timed execution with no steps; that is, n = 0 
and a = s for some s € start(RMg(A)). Since s.active-pkts = 0, the invariant assertion is trivially 
satisfied. 


For the inductive step, consider a timed execution a with k +1 steps. Let a’ be the prefix of 
a containing the first k steps of a and s’ be the last state of a’. The induction hypothesis is 
that for any active packet p’ € Prw-_curnr in 8’, i.e., p’ € s’.active-pkts, it is the case that either 
s’.now < s'.trans-time(p’) + A or s'.intended(p’) C s’.completed(p'). For the inductive step, we 
show that for any active packet p € Prm-curent in 8, 7.€., p € s.active-pkts, it is the case that either 
s.now < s.trans-tims(p) + A or s.intended(p) C s.completed(p). 


Suppose that p € s.active-pkts and consider two cases depending on whether p € s’.active-pkts. 
First, consider the case in which p ¢ s’.active-pkts. Lemma 4.11 implies that the step from s’ to s 
involves the action rm-senda(p), for h = source(p). Its effects are to set the variable trans-time(p) 
to now. It follows that s.now < s.trans-time(p) + A. Thus, the invariant assertion is satisfied in s. 


Second, consider the case in which p € s’.active-pkts. Then, the induction hypothesis implies that 
either s’.now < s'.trans-time(p)+A or s’.intended(p) C s’.completed(p). We proceed by considering 
the effects of each of the actions that affect any of the variables present in the invariant assertion: 
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O crash,, for h € H: the effects of this action are to remove the host h from the intended 
and completed delivery sets of p. Thus, the induction hypothesis implies that either s.now < 
s.trans-time(p) + A or s.intended(p) C s.completed(p). 


O rm-leave;,, for h € H: the reasoning for this action is similar to that of the crash, action. 


© rm-send;(p), for h = source(p): since p € s’.active-pkts it follows that p has been sent prior to 
state s’ within a. Thus, Lemma 4.2 implies that the rm-send;,(p) action is not enabled in s’. 


O rm-recv;(p), for h € H: we consider two cases depending on whether s’.erpected(h, source(p)) 
is empty. First, if s’.expected(h, source(p)) = @, the precondition of rm-recv;,(p) implies that 
s'.now < s'.trans-time(p) + A. Since the rm-recvp(p) action affects neither the now nor the 
trans-time(p) variables, it follows that s.now < s.trans-time(p)+A. Thus, the invariant assertion 
is satisfied in s. Second, if s’.erpected(h, source(p)) 4 0, the precondition of rm-recv;,(p) implies 
that id(p) € s'.expected(h, source(p)). The effects of rm-recv;(p) are to add the element 
id(p) to the set delivered(h, source(p)). Thus, the induction hypothesis implies that either 
s.now < s.trans-time(p) + A or s.intended(p) C s.completed(p). 


0 v(t), for t € R=°: the effects of the time-passage action are to allow ¢ time units to elapse. 
However, the precondition of the action v(t) implies that the invariant assertion is satisfied in s. 


4.3 Reliability Properties 


The RMs(A) automaton, for any A € R7° U ov, satisfies the eventual delivery and, equivalently, 
pairwise eventual delivery, properties. Eventual delivery is the property that if a host h is a 
member of the reliable multicast group, becomes aware of a packet p, remains a member of the 
group thereafter, and p remains active thereafter, then h delivers p since last joining the reliable 
multicast group. Its pairwise counterpart is the property that if two hosts are members of the 
reliable multicast group, become aware of the packet p, remain members of the group thereafter, 
and one of them delivers p since last joining the reliable multicast group, then so does the other. 
The eventual and pairwise eventual delivery properties are equivalent. 


Theorem 4.15 (Eventual Delivery) Let 6 be any fair admissible timed trace of RMs(A), for 
any A € R2° U oo, containing the transmission of a packet p € PrM-cunnr- If p € active-pkts(3), 
then p is delivered by each host in the intended delivery set of p within B since each such host last 
joined the reliable multicast group; that is, intended(p, 3) C completed(p, 3). 


Proof: Let a be any fair admissible timed execution of RMs(A), such that 3 = ttrace(a). Suppose 
that p € active-pkts(3) and let h € intended(p, 3). It suffices to show that h € completed(p, (3). 


First, we consider the case where h is the source of p. Since h € intended(p, 3), Definition 4.2 
implies that the last rm-join-ack, action in @ is succeeded by a rm-send;(p’) action, where 
source(p’) = source(p) and segno(p’) < seqno(p). If seqno(p’) = seqno(p) and, consequently, p’ = p, 
then it is the case that the last rm-join-ack,, action in ( is succeeded by a rm-send;,(p) action. 
By Definition 4.3, it follows that h € completed(p, 3), as needed. If seqno(p’) < seqno(p), then 
Lemma 4.3 implies that the transmission of p in 3 succeeds the transmission of p’ in 3. Since the 
rm-send};(p') action succeeds the last rm-join-ack,, action in 3, so does the rm-sendp(p) action. 
By Definition 4.3, it follows that h € completed(p, 3), as needed. 


Second, consider the case where h is not the source of p. Since h € intended(p, 3), Definition 4.2 
implies that the last rm-join-ack,;, action in 3 is succeeded by a rm-recv;(p’) action, where 
source(p’) = source(p) and segno(p’) < seqno(p). If seqno(p’) = seqno(p) and, consequently, 
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p' = p, then it is the case that the last rm-join-ack,, action in @ is succeeded by a rm-recup(p) 
action. By Definition 4.3, it follows that h € completed(p, 3), as needed. 


Now, consider the case where seqno(p’) < seqno(p). Let (s‘_,7,s',) be the discrete transition 
in a@ corresponding to the particular occurrence of the rm-recv;(p’) action in 3 and a’ be the 
suffix of a that starts in the post-state s‘, of (s‘_,7,s/,). Moreover, let sy be any state in a’. 
Since h € intended(p, 3), Lemma 4.7 implies that h € members((). Since a’ succeeds the last 
rm-join-ack, action in a, Lemma 4.6 implies that h € sq:.members. Since h # source(p), it 
follows that h € sq.members\{source(p)}. The precondition and the effects of the rm-recv;(p’) 
action imply that id(p) € s!, .expected(h, source(p)). Moreover, Lemma 4.14 implies that id(p) € 
Sq’ expected(h, source(p)). 


Moreover, let (s”,7, 8") be the discrete transition in a corresponding to the occurrence of the 
rm-sendp)(p) action in 3, for h’ = source(p), and a” be the suffix of a that starts in the post-state 
s" of (s”,7,8'.). Moreover, let sq” be any state in a”. Lemma 4.12 implies that p € s!.sent-pkts 


and Lemma 4.13 implies that p € sqv.sent-pkts. 


Now, let a* be any timed execution fragment that is a common suffix of a’ and a” and let 
s* be any state in a*. Since h € Ss :.members\{source(p)}, p € Sqv.sent-pkts, and id(p) € 
Sq’ .expected(h, source(p)), it is the case that h € s*.members\{source(p)}, p € s*.sent-pkts, and 
id(p) € s*.expected(h, source(p)). Thus, the rm-recv;(p) action is enabled in s*; that is, the 
rm-recv;,(p) action is enabled in any state in a*. 

Since a* is a suffix of a and a is an admissible timed execution of RMs5(A), it is the case that 
a* is infinite. Since the rm-recva(p) action is enabled in any state of a*, the rm-recup(p) action 
is enabled infinitely often in a*. Since a is fair, the rm-recv;,(p) action occurs in a*. Thus, the 
rm-recvp(p) action succeeds the last rm-join-ack, action in a. By Definition 4.3, it follows that 
h € completed(p, 3), as needed. |_| 


The following theorem defines the pairwise eventual delivery property of RM (A). It states that 
if two hosts are members of the reliable multicast group, become aware of the packet p, remain 
members of the group thereafter, and one of them delivers p, then so does the other. The pairwise 
eventual delivery is equivalent to the eventual delivery property defined in Theorem 4.15. 


Corollary 4.16 (Pairwise Eventual Delivery) Let 3 be any fair admissible timed trace of 
the RMs(A) automaton, for any A € R° U oo, that contains the transmission of a packet 
p € Pru-curnr and the hosts h,h' € H,h #h’ be any two distinct hosts in the intended delivery set 
of p within B. Then, if h delivers p within B, then so does h’. 


Proof: Since fh is in the intended delivery set of p within ( and it delivers p within (, it follows 
that p is active within (3; that is, p € active-pkts(3). Since h’ is in the intended delivery set of p 
within 6, Theorem 4.15 implies that h’ delivers p within 3. a 


The following theorem defines the notion of time-bounded delivery; that is, the property that any 
packet that remains active for at least A € R=° time units past its transmission is delivered within 
these A time units to all hosts that become aware of it within these A time units. 


Theorem 4.17 (Time-Bounded Delivery) Let @ be any admissible timed trace of RM(A) x 
RMCLIENTS, for any A € R2°, that contains the transmission of a packet p € Prm-curmnr. Let 3" 
be the finite prefix of 3 ending with the transmission of p; that is, the last action contained in 3 
is the action rm-send;(p), for h © H,h = source(p). Let 3” be any finite prefix of 3, such that 
Bi < BY < Bandt +A < t", with t,t” € R2° being the time of occurrence of the last actions 
of 3’ and 3", respectively. Suppose that the host h’ is in the intended delivery set of p within 3” 
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and that the packet p is active within B". Then, the host h delivers the packet p within B"; that is, 
h' € completed (p, 3”). 


Proof: Let a be any admissible execution of RM(A) x RMCLIENTS such that 3 = ttrace(q). 
Moreover, let a’ and a” be finite prefixes of a such that a’ < a” < a, '’ = ttrace(a’), 
B" = ttrace(a”), and the last actions in a’ and a” are the last actions in 3’ and 3”, respectively. 
Finally, let s’ and s” be the last states of a’ and a”, respectively. 


Since t+ A < t”, it follows that s”.trans-time(p) + A < s”.now. Since p € active-pkts(B"), 
Lemma 4.10 implies that p € s”.active-pkts. Since p € s”.active-pkts and s’.trans-time(p) +A < 
s” now, Invariant 4.3 implies that s”.intended(p) C s”.completed(p). Lemmas 4.8 and 4.9, imply 
that intended(p, 3”) C completed(p, 6”). Finally, since h’ € intended(p, 3”), it follows that 
h' € completed(p, 3"); that is, the host h’ delivers the packet p within (”. |_| 


5 Reliable Multicast Implementation (RMI) 


In this section, we present RMI — a formal model of the Scalable Reliable Multicast (SRM) 
protocol {1]. RMI precisely specifies the behavior of the basic version of SRM — more sophisticated 
versions involve adaptive and local recovery schemes [1,5]. 


5.1 Overview of RMI’s Functionality 


RMI consists of two distinct functional components: i) packet loss recovery, and ii) session message 
exchange. We proceed by describing each of these components. 


Packet Loss Recovery Receivers detect packet losses by identifying sequence number gaps in 
the stream of packets received from each source. Upon detecting the loss of a packet p, a host 
h initiates a new recovery round for p by scheduling a retransmission request for p. This request 
is scheduled for transmission at a point in time in the future that is uniformly chosen within the 
interval [Cidns, (Cy + C2)dps|, where Ci, C2 € R2° are request scheduling parameters and dj, is 
half of h’s round-trip-time (RTT) estimate to the source s of the packet p. 


Upon either the transmission of a request for p or the reception of a request for p while a request 
for p is pending transmission, the host h initiates a new recovery round for p by rescheduling the 
request for p for transmission at a point in time in the future that is uniformly chosen within the 
interval 2*-!{Cy dps, (C1 + C2)dns], where k € N* is the number of recovery rounds for p that h has 
already initiated. In effect, the request for p is rescheduled by performing an exponential back-off. 
If h receives p while a request for p is pending transmission, then the request for p is canceled. 


Once h reschedules its request for p, it observes a back-off abstinence period. During this period, 
it refrains from backing-off its request for p. Any requests for p received during this period are 
considered to pertain to prior recovery rounds and are discarded. Thus, back-off abstinence periods 
prevent requests from being backed-off multiple times by requests pertaining to the same recovery 
round. The back-off abstinence period for p expires at the point in time that is 2'-1C3d),, time 
units in the future, where k € N* is the number of recovery rounds for p that h has already initiated 
and C3 € R2° is the back-off abstinence parameter. 


Our modeling of back-off abstinence periods departs slightly from SRM. Floyd et al. [1] propose 
two schemes for ensuring that requests are backed off only once per recovery round. The first 
scheme involves back-off abstinence periods that expire once half the time to the transmission time 
of the respective request has elapsed. Our use of a parameter for specifying how long to abstain 
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from backing off allows more tuning freedom. Moreover, having back-off abstinence periods expire 
once half the time to the transmission time of the respective request has elapsed allows for the 
back-off abstinence period to overlap the interval within which requests are scheduled. This seems 
to go against the intention of the abstinence period. Requests received within the interval within 
which the current request was scheduled, should be considered to be requests of the current round 
and, thus, should result in the rescheduling of the current request. The second scheme annotates 
requests with their recovery round and backs off requests only upon receiving a request pertaining 
to the same or, presumably, a later round. 


If a host h’ receives a request for the packet p from the host h and it has already either 
sent or received p, then it schedules a reply for (retransmission of) p. This reply is scheduled 
for transmission at a point in time in the future that is uniformly chosen within the interval 
[Didnn, (Di + Dz)dyn], where D;, D2 € R2° are reply scheduling parameters and dj», is half of 
h’s RTT estimate to h (the requestor of p). If h’ receives a reply for p while its own reply for p is 
pending transmission, then h’ cancels its own reply for p. 


Once h’ either receives a reply for p or retransmits p itself, it observes a reply abstinence period; 
a period during which it refrains from scheduling replies to requests for p. The reply abstinence 
period for p expires at the point in time that is D3dpn: time units in the future, where D3 € R2° is 
the reply abstinence parameter. The reply abstinence period prevents multiple requests pertaining 
to a given recovery round from generating multiple replies. 


Session Message Exchange The reliable multicast group members periodically exchange 
session messages. These messages carry transmission state and timing information that allow 
the prompt detection of packet losses and the calculation of inter-host distance estimates; within 
SRM, inter-host distances are quantified by the one-way transmission latency between hosts. For 
simplicity, we assume that hosts transmit session messages with a fixed period. In practice however, 
so as to limit the overhead associated with the exchange of session messages, the frequency of session 
message transmission is reduced as the size of the reliable multicast group grows. 


Receivers detect packet losses by detecting sequence number gaps in the stream of packets received 
from each source. However, this approach presumes either that later packets within the sequence 
of transmitted packets are received, or that receivers get informed of the transmission progress 
of each source through a separate service. Unfortunately, relying solely on the reception of later 
packets may result in long recovery latencies. This is evident when the total number of packets 
within a sequence is unknown a priori and either long transmission pauses, or long loss bursts are 
considered. Session messages mitigate this problem by allowing reliable multicast group members to 
exchange transmission progress state, in terms of ADU sequence numbers that they have observed 
with respect to each source. Discrepancies in the observed transmission progress for each source 
by each host reveal whether and which packets a particular host is missing. 


In addition to contributing to packet loss detection, session messages are used to calculate inter-host 
distance estimates. Hosts estimate the one-way transmission latencies between them by exchanging 
timing information through their session messages. For the purposes of illustration, we demonstrate 
how a host h calculates its distance estimate to a host h’. This calculation is initiated when the host 
h transmits a session message, p. This session message includes a field containing its transmission 
time t,. Let t}, denote the time the host h’ receives p. Upon receiving p, h’ records the times at 
which p was transmitted and received, i.e., it records a tuple of the form (t,,t/.). Subsequently, the 
host h’ includes the tuple (ts,t/;) within its next session message, p’, where t!, corresponds to the 
time elapsed since the host h’ received p and the time h’ transmits p’. Finally, letting t, denote the 
point in time that h receives p’, h estimates its distance dnp to h! as (t, — tl, — ts)/2 time units. 


Although the above scheme for calculating inter-host transmission latencies is simple, it presumes 
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that inter-host transmission latencies are symmetric — the one way inter-host transmission 
latency is estimated as half the round-trip-time (RTT) between hosts. Another drawback of this 
scheme is the dependence of its accuracy on the frequency of session message transmission. The 
frequency of calculating inter-host distance estimates is dictated by the frequency of session message 
transmission. Thus, if the frequency of session message transmission were adjusted based on the 
size of the reliable multicast group, then as the group would increase in size the accuracy of the 
inter-host distance estimates would drop. 


5.2 Formal Model of RMI 


Presuming the abstract view of the physical system introduced in Section 3, RMI involves the 
interaction of a set of client processes, one process per host, a set of reliable multicast processes, 
one process per host, and an IP multicast service component. The client processes are identical to 
those presented in Section 4. The reliable multicast processes execute the SRM protocol. The IP 
multicast service component encapsulates the behavior of all communication processes at all hosts 
and the underlying network and provides the best-effort multicast primitive. 


We model each reliable multicast process as four interacting components, each with distinct 
functionalities. The membership component manages the reliable multicast group membership of 
the host. It handles the join and leave requests of the client process and issues join and leave requests 
to the underlying IP multicast service. The IP buffer component buffers all packets either received 
from or to be transmitted using the underlying IP multicast service. The recovery component 
incorporates all the functionality pertaining to the detection and recovery of missing packets. 
Finally, the reporting component incorporates all the functionality pertaining to the exchange of 
session messages among the members of the reliable multicast group. Session messages are used to 
exchange transmission state and inter-host round-trip-time (RTT) information. This information 
aids the detection of losses, in particular during transmission gaps, and the calculation of inter-host 
round-trip-time estimates, which are required by the recovery component. 


Figure 5 depicts the interaction of the various components of RMI. The reliable multicast process 
SRMy, at each host h is the composition of the automata SRM-MEM;,, SRM-IPBUFF,, SRM-RECp, 
and SRM-REP;,. The reliable multicast implementation as a whole, denoted SRM, is the 
composition of the SRM processes and the underlying IP multicast service after hiding all output 
actions that are not output actions of the specification RM(A), for any A € R=° U oo; that is, 
SRM = hidee([]ne4 SRMn x IPMcast), with ® = out([],<¢4 SRM»; x IPMcast)\out(RM(A)). 
Finally, we define RM; to be the composition of the reliable multicast implementation with all the 
client automata; that is, RM; = SRM x RM-CLIENTS. 


5.2.1 Preliminary Definitions 


Figure 6 contains a list of set definitions that specify the format of the various types of packets 
used throughout the following sections. The set Prw-cumnr represents the set of packets that may 
be transmitted by the client processes using the reliable multicast service. As defined in Section 4, 
for any packet p € Prw-cumnr the operations source(p), seqgno(p), and data(p) extract the source, 
sequence number, and data segment corresponding to the packet p. For shorthand, we use the 
operation id(p) to extract the identifier of p; that is, its source and sequence number pair. 


The set Pspm is comprised of all packets whose format is that used by the reliable multicast process. 
The format of each packet p € Psrm depends on its type. The type of the packet p, type(p), is 
one of the following: DATA, RQST, REPL, and SESS. The type of p denotes whether the packet is an 
original transmission, a repair request, a repair reply, or a session packet, respectively. Depending 
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Figure 5 Reliable Multicast Implementation Component Interaction 
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on its type, the packet p supports a different set of operations. 


When the packet p is an original transmission, that is, when type(p) = DATA, p supports the 
operations sender(p), source(p), seqno(p), data(p), and strip(p). These operations extract the 
sender, source, sequence number, data segment, and ADU corresponding to p. In the case of 
original transmissions, it is the case that sender(p) = source(p). When p is a repair request, that 
is, when type(p) = RQST, p supports the operations sender(p), source(p), and seqno(p). These 
operations extract the sender, source, and sequence number corresponding to the packet p. When 
p is a repair reply, that is, when type(p) = REPL, p supports the operations sender(p), source(p), 
seqno(p), data(p), and strip(p). These operations extract the sender, source, sequence number, 
data segment, and ADU packet corresponding to p. For DATA, RQST, and REPL packets, we also use 
the operation id(p) to extract the identifier of p; that is, its source and sequence number pair. 


When the packet p is a session packet, that is, when type(p) = SESS, p supports the operations 
sender(p), time-sent(p), dist-rprt?(p), dist-rprt(p, h), and seqno-rprts(p). The operation sender (p) 
extracts the sender of the session packet. The operation time-sent(p) extracts the time the session 
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packet p was sent. The operation dist-rprt?(p) extracts the set of hosts for which the session 
packet is distance reporting. The operation dist-rprt(p, h) extracts the distance report for h within 
p; that is, dist-rprt(p,h) corresponds to a tuple comprised of two elements: the time the most 
recently observed session packet sent by h was received by the sender of p and the time that 
elapsed between the reception of h’s session packet by the sender of p and the transmission of 
p. The operation seqno-rprts(p) extracts the state reports included in p; that is, seqno-rprts(p) 
corresponds to a set of tuples, each of which is comprised of two elements: the source and the 
maximum sequence number observed by the sender of p to have been transmitted by this source. 


The set Pipacast-Cuentr represents the set of packets that may be transmitted by the clients of the 
IP multicast service. For any packet p € Pipmcasr-Curnr the operations source(p), seqno(p), and 
strip(p) extract the source, the sequence number, and the data packet encapsulated in p. 


The set Ptpmcasr is comprised of tuples, each of which describes the transmission progress of a 
particular packet transmitted using the IP multicast service. We refer to the tuples comprising 
Prpmcasr aS IP multicast progress packets or transmission progress tuples. For any element pkt 
of Prpmcast, the operations strip(pkt), intended(pkt), completed(pkt), dropped(pkt) extract the 
packet, the intended delivery set, the completed delivery set, and the dropped set corresponding 
to pkt. Letting p = strip(pkt), the intended delivery set of pkt is the set of hosts that were and 
have remained members of the IP multicast group following the transmission of p. The completed 
delivery set of pkt is the set of hosts to which p has already been delivered. The dropped set of 
pkt is the set of hosts to which the IP multicast service can no longer deliver the packet p due to 
packet drops. 


Figure 7 contains a list of set definitions used throughout the following sections. 


5.2.2. The Membership Component — SRM-MEM), 


The SRM-MEm,, timed I/O automaton specifies the membership component of the reliable 
multicast process. Figures 8 and 9 present the signature, the variables, and the discrete transitions 
of SRM-MEMp,. 


Variables The variable now € R2° denotes the time that has elapsed since the beginning 
of an execution of SRM-MEM;. The variable status captures the status of the host h. It 
evaluates to one of the following: idle, join-rqst-pending, join-pending, join-ack-pending, 
leave-rqst-pending, leave-pending, leave-ack-pending, member, and crashed. 


The value idle indicates that the host h is idle with respect to the reliable multicast group; that 
is, it is neither a member, nor in the process of joining or leaving the reliable multicast group. The 
value join-rqst-pending indicates that SRM-MEM~, has received a join request from the client 
but has yet to issue a join request to the underlying IP multicast service. The value join-pending 
indicates that SRM-MEM, has issued a join request to the underlying IP multicast service and 
is awaiting a join acknowledgment. The value join-ack-pending indicates that SRM-MEM, has 
successfully joined the underlying IP multicast service but has yet to issue a join acknowledgment 
to the client. The value member indicates that the host h is a member of the reliable multicast 
group. The value leave-rqst-pending indicates that SRM-MEMy, has received a leave request 
from the client but has yet to issue a leave request to the underlying IP multicast service. The 
value leave-pending indicates that SRM-MEM~, has issued a leave request to the underlying IP 
multicast service and is awaiting a leave acknowledgment. The value leave-ack-pending indicates 
that SRM-MEMy,, has successfully left the underlying IP multicast service but has yet to issue a 
leave acknowledgment to the client. The value crashed indicates that the host h has crashed. 
While the host h has not crashed, we say that it is operational. Once the host h crashes, none 
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Figure 6 SRM Packet Definitions 


Prwe-curnt = Set of packets such that V p € Prw-curnr 
source(p) € H 
seqno(p) EN 
data(p) € {0,1}" 
id(p) € H x N: id(p) = (source(p), seqno(p)) 
suffiz(p) = {(s,t) € H x N | source(p) = s A seqno(p) < i} 


Pao-Curnt[h] = {p © Pao-cunr | source(p) = h} 


Pgrm = Set of packets such that Vp € Pspm 
type(p) € {DATA, RQST, REPL, SESS} 
DATA: 
sender(p) € H 
source(p) € H 
seqno(p) EN 
data(p) € {0, 1}* 
strip(p) © PaM-cusyr 
id(p) € Hx N: id(p) = (source(p), seqno(p)) 
RQST : 
sender(p) € H 
source(p) € H 
seqno(p) EN 
id(p) € Hx N : id(p) = (source(p), seqno(p)) 
REPL : 
sender(p) € H 
source(p) € H 
seqno(p) EN 
data(p) € {0, 1}* 
strip(p) € PRM-Cunr 
id(p) € Hx N : id(p) = (source(p), seqno(p)) 
SESS : 
sender(p) € H 
time-sent(p) € R2° 
dist-rprt?(p) C H 
dist-rprt(p, h) € {(t, t’) | t,t’ € R29}, for allh C H 
seqno-rprts(p) C {(s,i) |s € H,ie N} 


Pipmcast-Cunr = Set of packets such that Vp € Prpucast-Cumnt! 
source(p) © H 
seqno(p) EN 
strip(p) € {0,1}* 


Prpucasr = Set of packets such that V pkt € Pipmcasr: 
strip(pkt) © Prpcast-Cuent 
intended(pkt) C H 
completed(pkt) C H 
dropped(pkt) C H 


Figure 7 SRM Set Definitions 


Pending-Rqsts = {(s,i,t) | s € H,ie N,t € R29} 
Scheduled-Rqsts = {(s,i,t,k) | s € Hie N,t € R2°,k e N} 
Pending-Repls = {(s,i,t) | s € H,i¢ N,t € R2°} 
Scheduled-Repls = {(s,i,t,r) | s,r € H,i € N,t € R2°} 


SRM-Status = {idle, member, crashed} 

Joining = {join-rqst-pending, join-pending, join-ack-pending} 

Leaving = {leave-rqst-pending, leave-pending, leave-ack-pending} 

SRM-Mem-Status = SRM-Status U Joining U Leaving 

Action-Pending = {join-rqst-pending, join-ack-pending, leave-rqst-pending, leave-ack-pending} 


IPmcast-Status = {idle, joining, leaving, member, crashed} 
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Figure 8 The SRM-MEM, Automaton — Signature 


Parameters: 
heH 

Actions: 

input output 
crash, mjoinp, 
rm-joinp, mleavep;,, 


rm-leave;, 
mjoin-ackp, 
mleave-acky, 


rm-join-ackp, 

rm-leave-ackp, 
time-passage 

v(t), for t € R2° 


Figure 9 The SRM-MEM;, Automaton — Variables and Discrete Transitions 


Variables: 


now € R2°, initially now = 0 


status € SRM-Mem-Status, initially status = idle 


Discrete Transitions: 


input crash; 
eff status := crashed 
input rm-joinp, 
eff if status = idle then 
status := join-rqst-pending 
input rm-leave, 


eff if status € Joining U {member} then 
status := leave-rqst-pending 


output mjoin, 

pre status = join-rqst-pending 
eff status := join-pending 
output mleave,;, 


pre status = leave-rqst-pending 
eff status := leave-pending 


output rm-join-ack);, 


pre status = join-ack-pending 


: Be eff status := member 
input mjoin-ack;, 


eff if status € Joining then output rm-leave-ackp, 


status := join-ack-pending pre status = leave-ack-pending 


input mleave-ack;, eH Satie 22008 


eff if status € Leaving then time-passage v(t) 
status := leave-ack-pending pre status ¢ Action-Pending 


eff now := now+t 


of the input actions of SRM-MEMy, affect the state of SRM-MEM,, and none of the internal and 
output actions of SRM-MEMp, except the time passage action, are enabled. 


Input Actions The input action crash, models the crashing of SRM-MEM,). The effects of 
crash, are to set the u variable to False, denoting that SRM-MEM~, has crashed. 


The input action rm-join;, models the client’s request to join the reliable multicast group. It is 
effective only when the host h is idle with respect to the reliable multicast group. If the client 
h is already either a member of, or in the process of joining, the reliable multicast group (that 
is, status € Joining U {member}), then the scheduling of rm-join, is superfluous. If the client h 
is already in the process of leaving the reliable multicast group (that is, status € Leaving), then 
rm-joiny is ignored so as to allow the ongoing process of leaving the reliable multicast group to 
complete. When effective, rm-join, initiates the process of joining the reliable multicast group by 
setting the status variable to join-rqst-pending. 


The input action rm-leave;, models the client’s request to leave the reliable multicast group. 
It is effective only when the host h is either a member of, or in the process of joining, the 
reliable multicast group. If the host h is either already in the process of leaving, or idle with 
respect to the reliable multicast group, then the rm-leave, action is superfluous. When effective, 
rm-leavey initiates the process of leaving the reliable multicast group by setting the status variable 
to leave-rqst-pending. 
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The input action mjoin-acky, acknowledges that the host h has successfully joined the underlying IP 
multicast group. It is effective only when the host h is in the process of joining the reliable multicast 
group; that is, when status € Joining. When effective, mjoin-ack, enables the I/O component to 
acknowledge the client’s join request by setting the status variable to join-ack-pending. 


The input action mleave-ack,, acknowledges that the host h has successfully left the underlying 
IP multicast group. It is effective only when the host h is in the process of leaving the reliable 
multicast group; that is, when status € Leaving. When effective, mleave-acky, sets the status 
variable to leave-ack-pending. Thus, it enables the I/O component to acknowledge the client’s 
leave request. 


Output Actions SRM-MEMy initiates the process of joining of the underlying IP multicast group 
by scheduling the output action mjoin;. This action is enabled whenever the client has effectively 
requested to join the reliable multicast group; that is, when status = join-rqst-pending. Its 
effects are to record the fact that SRM-MEMy,, has requested to join the IP multicast group; that 
is, it sets the status variable to join-pending. Joining the underlying IP multicast group is not 
always immediate. In order for the IP multicast service to forward packets to the host h, it may 
have to extend the IP multicast tree to include the host h. The time involved in extending the IP 
multicast tree to include the host h heavily depends on the location of the host h and the reach of 
the current IP multicast tree. 


SRM-MEMy, initiates the process of leaving of the underlying IP multicast group by scheduling 
the output action mleave,. This action is enabled whenever the client has effectively requested to 
leave the reliable multicast group; that is, status = leave-rqst-pending. Its effects are to record 
the fact that SRM-MEMy, has requested to leave the IP multicast group; that is, it sets the status 
variable to leave-pending. 


SRM-MEMy, acknowledges the client’s request to join the reliable multicast group by scheduling the 
rm-join-ack,, output action. This action is enabled whenever the join acknowledgment is pending; 
that is, status = join-ack-pending. Time is not allowed to elapse while a join acknowledgment is 
pending. Thus, a join acknowledgement is sent immediately after SRM-MEMy, determines that it 
has successfully joined the IP multicast group. 


SRM-MEmy, acknowledges the client’s request to leave the reliable multicast group by scheduling 
the rm-leave-ack,, output action. This action is enabled whenever the leave acknowledgment 
is pending; that is, status = leave-ack-pending. Time is not allowed to elapse while a leave 
acknowledgment is pending. Thus, a leave acknowledgement is sent immediately after SRM-MEMy, 
determines that it has successfully left the IP multicast group. 


Time Passage The action v(t) models the passage of t time units. Time is prevented from 
elapsing while there are pending actions — either pending requests to join or leave the underlying 
IP multicast group, or pending acknowledgments that the client has successfully joined or left the 
reliable multicast group. The effects of the v(t) action are to increment the variable now by t time 
units. 


5.2.3. The IP Buffer Component — SRM-IPBUFF, 
The SRM-IPBuFFy, timed I/O automaton specifies the IP buffer component of the reliable multicast 


process. Figures 10 and 11 present the signature, the variables, and the discrete transitions of 
SRM-IPBUFF». 
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Figure 10 The SRM-IPBuUFF, Automaton — Signature 


Parameters: 
heH 

Actions: 

input output 
crash), process-mpkt,(p), for p € Psp 
rm-join-ack;, msend), (p), for p € Pipacasr-Cuent 
rm-leavep, time-passage 
mrecvp(p), for p © Prpacasr-Cuimnr v(t), for t € R2° 


rep-msend)(p), for p € Psrm 
rec-msend,, (p), for p € Psp 


Figure 11 The SRM-IPBuUFF, Automaton — Variables and Discrete Transitions 


Variables: 


now € R2°, initially now =0 

status € SRM-Status, initially status = idle 

seqno EN, initially segno = 0 

msend-buff C Prpucast-Cunt; initially mrecv-buff = 0 
mrecv-buff © Prpmcasr-Curnr; initially mrecv-buff = 0 


Discrete Transitions: 


input crash, input rec-msend, (p) 


eff status := crashed eff if status = member then 
input m-join-ack;, msend-buff U= {comp-IPmcast-pkt(h, seqno, p)} 
seqno := seqno+1 
eff if status #4 crashed then status := member 
output process-mpkt, (p) 


input rm-leave 
p h choose pkt € Pipycast-Cuent 


eff if status # crashed then pre status = member A pkt € mrecv-buff A p = strip(pkt) 
Reinitialize all variables except now and seqno. eff mrecv-buff \= {pkt} 

input mrecv;,(p) output msend, (p) 

eff if status = member then mrecv-buff U= {p} pre status = member A p € msend-buff 

input rep-msend),, (p) eff msend-buff \= {p} 

eff if status = member then time-passage v(t) 
msend-buff U= {comp-IPmcast-pkt(h, seqno, p) } pre status = crashed V (msend-buff = @ A mrecv-buff = 0) 
seqno := seqno+1 eff now := now +t 


Variables The variable now € R2° denotes the time that has elapsed since the beginning of an 
execution of SRM-IPBUFF,. The variable status captures the status of the host h. It evaluates to 
one of the following: idle, member, and crashed. While the host h has not crashed, we say that 
it is operational. Once the host fA has crashed, none of the input actions of SRM-IPBUFFy, affect 
the state of SRM-IPBUFF,, and none of the internal and output actions of SRM-IPBUFF;), except 
the time passage action, are enabled. The variable segno € N is a counter of the number of packets 
transmitted by SRM-IPBUFFy,, using the underlying IP multicast service. 


The sets msend-buff and mrecv-buff are used to buffer all packets to be sent by and received from, 
respectively, the underlying IP multicast service. 


Input Actions The input action crash; models the crashing of SRM-IPBUFF,. The effects of 
crash, are to set the status variable to crashed, denoting that the host h has crashed. After the 
host A has crashed, the SRM-IPBUFF, automaton does not restrict time from elapsing. 


The input action rm-join-ack, informs the SRM-IPBUFF, automaton that the host h has joined 
the reliable multicast group. If the host h is operational, then the action rm-join-acky,, records 
the fact that the host h has joined the reliable multicast group by setting the variable status to 
member. 


The input action rm-leave, informs the SRM-IPBUFF,, automaton that the host h has left the 
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reliable multicast group. If the host h is operational, then the action rm-leavey,, reinitializes all the 
variables of SRM-IPBUFFy, except the variables now and seqno. 


The input action mrecv,(p) models the reception of the packet p from the underlying IP multicast 
service. If the host h is a member of the reliable multicast group, then the mrecv,(p) action adds 
the packet p to the mrecv-buff buffer. Thus, the contents of the packet p may subsequently be 
processed by the reliable multicast service and, when appropriate, delivered to the client. 


The input actions rep-msend;,(p) and rec-msenda(p) are performed by the reporting and recovery 
components, respectively, so as to transmit the packet p using the underlying IP multicast service. 
In the case of the rep-msend,(p) action, the packet p is a session packet. In the case of a 
rec-msend;(p) action, the packet p is either a data, a request, or a reply packet. 


If the host h is a member of the reliable multicast group, then SRM-IPBUFF,, encapsulates h, 
seqno, and p into a packet pkt, buffers pkt in msend-buff for transmission using the underlying IP 
multicast service, and increments seqno. In effect, the encapsulation of p annotates it with the host 
h and the value of segno. Since the variable seqno is persistent across host joins and leaves, packets 
transmitted by the SRM-IPBUFF, automata, for h € H, are unique. 


Output Actions The output action process-mpkt,;(p) models the processing of the packet p by 
the reporting and recovery components. It is enabled when the host h is a member of the reliable 
multicast group and there is a packet pkt in the mrecv-buff buffer, such that strip(pkt) = p. Its 
effects are to remove the element pkt from the mrecv-buff buffer. 


The output action msend;(p) models the transmission of the packet p using the underlying IP 
multicast service. It is enabled when the host h is a member of the group and the packet p is in 
the msend-buff buffer. Its effects are to remove the packet p from the msend-buff buffer. 


Time Passage The action v(t) models the passage of t time units. Time is prevented from 
elapsing while the host h is operational and either of the buffers msend-buff and mrecv-buff is 
non-empty. The effects of the v(t) action are to increment the variable now by t time units. 


5.2.4 The Recovery Component — SRM-REC,, 


The SRM-REC, timed I/O automaton specifies the recovery component of the reliable multicast 
service. Figure 12 presents the signature of SRM-REc,, that is, its parameters, and actions. 
Figure 13 presents the variables of SRM-RECa. Figures 14 and 15 present the discrete transitions 
of SRM-RECa. In order to provide the appropriate context, the description of each of the parameters 
of SRM-REC,, is deferred to appropriate places within the description of its variables and actions. 


Variables The variable now € R2° denotes the time that has elapsed since the beginning of an 
execution of SRM-REc,. The variable status captures the status of the host h. It evaluates to 
one of the following: idle, member, and crashed. While the host h has not crashed, we say that 
it is operational. Each of the dist(h’) € R=° variables, for h’ € H,h’ # h, denotes the host h’s 
distance estimate to the host h’. Each of the dist(h’) variables are initialized to the parameter 
DFLT-DIST. Each of the min-segno(h’) € N and maz-segno(h’) € N variables, for h’ € H, denotes 
the minimum and maximum ADU sequence numbers observed to have been transmitted by the 
host h’. The variable archived-pkts C PrM-curnr X R2° is comprised of pairs involving the ADUs 
that have either been sent by or buffered for delivery to the client at A and the first point in time 
at which each ADU has either been sent by or buffered for delivery to the client at h. The variable 
to-be-requested C H x N denotes the set of ADU packets that have been identified as missing and 
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for which a request has yet to be scheduled. The elements of to-be-requested are tuples of the form 
(s,7), with s € H andi € N denoting the source s and the sequence number i of the missing ADU. 


The set pending-rgqsts C Pending-Rgqsts is comprised of tuples that correspond to packets for which 
a request is pending; that is, a request for the particular packet has recently either been sent or 
received and a reply is being awaited. The tuples of pending-rqsts are of the form (s,i,t), with 
s € H,i € N,t € R@°; s and i represent the source and sequence number of the packet whose 
request is pending and ¢ represents the back-off abstinence deadline; that is, the time before which 
the request timeout timer for the given packet may not be backed off. A pending request expires 
when time elapses past its back-off abstinence timeout. Prior to its expiration, a pending request 
is said to be active. 


The set scheduled-rqsts C Scheduled-Rqsts is comprised of tuples that correspond to packets for 
which a request has been scheduled and is awaiting transmission. The tuples of scheduled-rqsts are 
of the form (s,i,t,k), with s € H,i ¢ N,t € R=°,k € N; s and i correspond to the source and 
sequence number of the packet to be requested, t is the time for which the request is scheduled 
for transmission, and k& is the number of times a request for the given packet has already been 
scheduled. 


The set pending-repls C Pending-Repls is comprised of tuples that correspond to packets for which 
a reply has recently been either sent or received. The tuples of pending-repls are of the form (s, 7, t), 
with s € H,i € N,t € R@°; s and i correspond to the source and sequence number of the packet for 
which a reply has already been either sent or received and t is the abstinence timeout of the reply; 
that is, a deadline before which replies for the given packet may not be scheduled by the host h. 
A pending reply expires when time elapses past its abstinence timeout. Prior to its expiration, a 
pending reply is said to be active. 


The set scheduled-repls C Scheduled-Repls is comprised of tuples that correspond to packets for 
which a reply has been scheduled and is awaiting transmission. The tuples comprising the set 
scheduled-repls are of the form (s,i,t,r), with s,r € H,i © N,t € R°; s and i correspond to the 
source and sequence number of the packet to be retransmitted, t is the time for which the reply is 
scheduled for transmission, and r is the host whose request induced the scheduling of the particular 
reply. 

The set to-be-delivered C Prm-curenr is used to buffer the packets that are to be subsequently 
delivered to the client. The set msend-buff C Pgrm is used to buffer the packets that are to 
be subsequently multicast using the underlying IP multicast service; that is, it contains the data 


packets of the client and the requests and replies of the recovery component to be transmitted by 
the host h. 


Derived Variables The derived variable proper?(h’), for h’ € H, is the set comprised of the 
identifiers of the packets from h’ whose sequence numbers are no less than min-segno(h’). The 
derived variable window?(h’), for h’ € H, is the set comprised of the identifiers of the packets from 
h’ whose sequence numbers are no less than min-seqno(h’) and no greater than maz-segno(h’). 
The derived variable archived-pkts? C H x N identifies all the packets for which there is a 
corresponding tuple in the set archived-pkts. The derived variable archived-pkts?(h') C H x N, 
for h’ € H, identifies all the packets from h’ for which there is a corresponding tuple in the set 
archived-pkts. 


The derived variable to-be-requested(h’) C H x N, for h’ € H, identifies all the packets from h’ 
that are in the set to-be-requested. The derived variable to-be-delivered? C H x N identifies all the 
packets for which there is a corresponding tuple in the set to-be-delivered. The derived variable 
to-be-delivered?(h') C H x N, for h’ € H, identifies all the packets from h’ that are in the set 
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Figure 12 The SRM-REcy, Automaton — Signature 


Parameters: 


h € H, C1, Co, C3, D1, D2, D3 € R29, DFLT-DIST € R2° 


Actions: 

input time-passage 
crashp v(t), for t € R2° 
rm-join-ack;, internal 
rm-leave;, schdl-rqstp(s,i), fors € Hie N 
rm-send;(p), for p € PramM-cuenr send-rgstp(s,7), fors € Hie N 
rep-dist,(h’,d’), for h’ € H,h’ £h,d! € R2° send-replp,(s,7), fors € Hie N 
rep-seqno,(s,i), forse H,s #hiecNn output 
process-mpkt;,(p), for p € Psrm rm-recv,(p), for p € Pro-curnt 


rec-msend, (p), for p € Psp 


Figure 13 The SRM-REc, Automaton — Variables 


Variables: 


now € R2°, initially now =0 

status € SRM-Status, initially status = idle 

dist(h’) € R2°, for all h’ € H,h’ £h, initially dist(h’) = DFLT-DIST, for all h’ € H,h’ Ah 
min-seqno(h’) € NU L, for all h’ € H, initially min-seqno(h’) =, for all h’ € H 
maz-seqno(h') € NU L, for all h’ € H, initially maz-seqno(h’) =, for all h’ € H 
archived-pkts C PrM-cusnr X R2°, initially archived-pkts = 0 

to-be-requested C H x N, initially to-be-requested = 0 

pending-rgsts C Pending-Rgsts, initially pending-rqsts = 0 

scheduled-rqsts C Scheduled-Rgqsts, initially scheduled-rgqsts = 0 

pending-repls C Pending-Repls, initially pending-repls = @ 

scheduled-repls C Scheduled-Repls, initially scheduled-repls = 0 

to-be-delivered C Pry-curnr, initially to-be-delivered = 0 

msend-buff C Psrm, initially msend-buff = 0 


Derived Variables: 


0 if min-seqno(h’) =L 

{(s,i) € Hx N|s =h’, min-seqno(h’) < i} otherwise 

) if min-seqno(h’) =L 
{(s,i) € Hx N| s =h’, min-seqno(h’) < i < maz-segno(h’)} otherwise 
archived-pkts? = {(s,i) € H x N | dp © Pra-cuent,t € R20: (p,t) € archived-pkts \ id(p) = (s, i) } 
archived-pkts?(h’) = {(s,i) € archived-pkts? | s = h’}, for all h’ € H 

to-be-requested(h') = {(s,%) € to-be-requested | s = h’}, for all h’ © H 

to-be-delivered? = {(s,i) € H x N | dp € to-be-delivered : (s,i) = id(p)} 

to-be-delivered? (h’) = {(s,i) € to-be-delivered? | s = h’}, for all h’ € H 

scheduled-rgsts? = {(s,i) € Hx N| dt € R7°,k EN: (s,i,t,k) € scheduled-rqsts} 

scheduled-rgsts? (h’) = {(s, i) € scheduled- rdais? |s=h'} 

scheduled-repls? = {(s,i) € Hx N| Jt € R7°,r € H: (s,i,t,r) € scheduled-repls} 

pending-rgsts? = {(s,i) © Hx N| dt € R2°: now < tA (s,i,t) € pending-rqsts} 

pending-repls? = {(s,i) € Hx N| dt € R2°: now < tA (s,i,t) € pending-repls} 


for all h’ € H, proper?(h’) = 


for all h’ € H, window? (h’) = 


to-be-delivered?. 


The derived variable scheduled-rqsts? C H x N identifies all the packets for which there 
is a corresponding scheduled request tuple in the set scheduled-rqsts. The derived variable 
scheduled-rqsts?(h') C H x N, for h’ € H, identifies all the packets from h’ whose identifiers 
are in the set scheduled-rqsts?. The derived variable scheduled-repls? C H x N identifies all the 
packets for which there is a corresponding scheduled reply tuple in the set scheduled-repls. 


The derived variable pending-rqsts? C H x N identifies all the packets for which there is an active 
pending request; that is, there is a corresponding tuple in the set pending-rgqsts whose back-off 
abstinence timeout has not yet expired. The derived variable pending-repls? C H x N identifies all 
the packets for which there is an active pending reply; that is, there is a corresponding tuple in the 
set pending-repls whose abstinence timeout has not yet expired. 
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Input Actions The input action crash; models the crashing of the host h. The effects of crash; 
are to set the status variable to crashed. Once the host fh has crashed, none of the input actions 
of SRM-REC, affect its state, none of the internal and output actions of SRM-REC, are enabled, 
and time is not restricted from elapsing. 


The input action rm-join-ack, informs the SRM-REC, automaton that the host h has joined the 
reliable multicast group. If the host A is operational, then the rm-join-ack, action records the 
fact that the host h has joined the reliable multicast group by setting the variable status to member. 
Subsequently, SRM-REC; may transmit, process, and deliver packets and schedule packet requests 
and replies. 


The input action rm-leave,, informs the SRM-REC; automaton that the host h has left the reliable 
multicast group. If the host h is operational, then the action rm-leavey,, reinitializes all the variables 
of SRM-REC,, except the variable now. Subsequently, SRM-REC;, automaton ceases transmitting, 
processing, and delivering packets and scheduling packet requests and replies. 


The input action rm-send;(p) models the transmission of the packet p by the client at h using 
the reliable multicast service. rm-send;(p) is effective only when the host h is a member of the 
reliable multicast group and the host h is the source of the packet p. If p is the first packet 
to be transmitted by the client since it last joined the reliable multicast group, the rm-send;(p) 
action sets the min-segno(h) variable to the sequence number of p. Otherwise, SRM-RECy, ensures 
that p corresponds to the next packet awaited; that is, the packet whose sequence number is one 
larger than the sequence number of the latest packet transmitted by h. If so, SRM-REC, updates 
maz-seqno(h), archives p, and generates a DATA packet to subsequently be transmitted to the other 
members of the reliable multicast group through the underlying IP multicast service. The operation 
comp-data-pkt(p) composes a DATA packet corresponding to the client packet p. 


Each input action rep-dist,(h’,d’), for h’ € H,h’ 4 h,d’ © R=°, reports to SRM-REC;, an 
updated distance estimate d’ to h’. If the host h is a member of the reliable multicast group, then 
the rep-dist,(h’,d’) action sets the variable dist(h’) to the value d’. 


Each input action rep-seqno,(s,7), for s € H,s # h,i € N, reports to SRM-REc,, the 
latest observed sequence number 7 for the source s. If the host h is a member of the reliable 
multicast group, (s,7) corresponds to a proper packet, and i is greater than maz-seqno(s), 
then the rep-seqno,(s,7) action adds the packets from s with sequence numbers ranging from 
maxz-seqno(s) +1 to i to the set to-be-requested and sets maz-seqno(s) to 1. 


The input action process-mpkt,;(p) models the processing of the packet p by SRM-RECa;. The 
packet p is processed only when the host h is a member of the reliable multicast group. We proceed 
by describing the effects of process-mpkt;,(p) depending on the type of the packet p. When p is 
either a DATA, RQST, or REPL packet, we let s, € H and 7, € N denote the source and the sequence 
number pertaining to the packet p. 


First, consider the case where p is a DATA packet. If h is not the source of p and p is the first 
packet from s, to be received by h, then the variables min-seqno(sp») and maz-seqno(sp) are set 
to ip. Following this initial assignment of min-seqno(sp) to ip, all DATA, RQST, and REPL packets 
pertaining to ADUs from s, with sequence numbers less than 7, are considered improper and are 
discarded. Conversely, all DATA, RQST, and REPL packets pertaining to ADUs from s, with sequence 
numbers equal to or greater than 7, are considered proper and are processed. 


The processing of packet p proceeds only while it is considered a proper packet. Unless either h 
is the source of p or p is already archived, p is archived by adding the tuple {(strip(p), now)} to 
archived-pkts. Unless h is the source of p, the ADU contained in p is buffered in to-be-delivered so 
that it may subsequently be delivered to the client. Thus, the reliable multicast process does not 
deliver packets sent by a client to itself. Moreover, the reliable multicast service may also deliver 
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Figure 14 The SRM-REcy, Automaton — Discrete Transitions 


input crash; internal send-rqst p(s, 2) 

eff status := crashed choose t € R29,k EN 

pre status = member 

ss At = now A (s, i,t, k) € scheduled-rqsts 
eff if status 4 crashed then status := member eff \\ Compose request packet 

input rm-leavep, msend-buff U= {comp-rgqst-pkt(h, (s,7))} 
eff if status? crashed then \\ Back-off scheduled request 


aay cea : scheduled-rqsts \= {(s,i,t, k)} 
Reinitialize all variables except now. eee doa) 


input rm-join-ack, 


input rm-send, (p) ty :€ now + 2r-1 (Cy dy, (Cy + C2)dr] 
eff if status = member A h = source(p) then scheduled-rgsts U= {(s, i, tr, kr) } 
(Sp, ip) = id(p) \\ A request becomes pending 
\\ Record foremost DATA packet pending-rgsts \= {(s,i, tx) | tx € R2°} 
if min-seqno(sp) =L then min-seqno(sp) := ip tr = now + 2*r-1C3d, 
\\ Only consider next packet pending-rgsts U= {(s, i, tr) } 


if maz-seqno(sp) =L 


Vip = max-seqno(sp) +1 2 
0 
then choose t € R=",r ¢ H 


pre status = member 
At = now A (s,i,t,r) € scheduled-repls 


internal send-rep1)/(s, 2) 


max-seqno(Sp) := ip 
\\ Archive packet 


archived-pkts U= {(p, now) } eff \\ Compose reply packet . 
\\ Compose data packet choose p € PRM-Cumnr t € R2° 
msend-buff U= {comp-data-pkt(p) } where (p,t) € archived-pkts \ id(p) = (s,%) 


msend-buff U= {comp-repl-pkt(h, p) } 

\\ A reply becomes pending 

eff if status = member then pending-repls \= {(s,i,t«) | te € R2°} 
dist(h’) := d’ trept = now + D3dist(r) 

pending-repls U= {(s, a, trept) } 

\\ Cancel scheduled reply 


input rep-dist,, (h’,d’) 


input rep-seqnop (s, 7) 


eff if status = member ; scheduled-repls \= {(s, i, t,r)} 
Amin-seqno(s) AL Amaa-seqno(s) <i 
then output rm-recvy,, (p) 
to-be-requested U= pre status = member / p € to-be-delivered 
{(s,i’) | i’ € N, maz-segno(s) < i’ < i} A(fip! € to-be-delivered : 
maa-seqno(s) := 1 source(p’) = source(p) A seqno(p’) < seqno(p)) 


internal schdl-rqsty, (s, 7) eff to-be-delivered \= {p} 


pre status = member / (s,i) € to-be-requested output rec-msend), (p) 


eff \\ Schedule new request pre status = member A p € msend-buff 

ky := 1; dp := dist(s) eff msend-buff \= {p} 

tr :€ now + 2*r-1[Cy dr, (C1 + C2) dr] 

scheduled-rqsts U= {(s,1, tr, kr)} 

\\ Pkt request has been scheduled pre status = crashed 

to-be-requested \= {(s, t)} V (to-be-requested = 0 / to-be-delivered = 0 
Amsend-buff = 0 
A no requests scheduled earlier than now + t 
A no replies scheduled earlier than now + t) 

eff now := now+t 


time-passage v(t) 


the same ADU to the client multiple times. The identifier of the ADU pertaining to p is removed 
from the to-be-requested set and any scheduled requests and replies for the ADU pertaining to p 
are canceled. Finally, unless h is the source of p, SRM-RECy,, adds any trailing missing packets to 
the set to-be-requested, so that a request for each of them may subsequently be scheduled. 


Second, consider the case where p is a REPL packet. The processing of a a REPL packet is similar 
to that of a DATA packet. The differences are that p is processed only if it pertains to a proper 
ADU and that in addition to the effects of processing a DATA packet, a reply for the given ADU 
becomes pending. While this pending reply is active, SRM-REC,, does not schedule replies for the 
ADU pertaining to p. 

Third, consider the case where p is a RQST packet. Once again, p is processed only if it pertains to 
a proper ADU. If p pertains to an ADU that has been archived and for which a reply is neither 
scheduled, nor pending, then SRM-REcy, schedules a retransmission of the requested ADU. This 
retransmission is scheduled for a point it time in the future that is chosen uniformly within the 
interval now + [Di drepi, (D1 + D2)drepi|, with dren) = dist(sender(p)). If p pertains to an ADU that 
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has not been archived, then the effects of process-mpkt;,(p) depend on whether there is a request 
for the given ADU already scheduled. If h is not the source of p and there is no request for the ADU 
of p already scheduled, then a request for the given ADU is scheduled. This request is scheduled for 
a point it time in the future that is chosen uniformly within the interval now + 2[C1d,, (C1 + C2)d,], 
with d, = dist(sp); that is, the request is scheduled as if a first round request is being backed off. 
If h is not the source of p, there is a request for the ADU of p already scheduled and there, are 
there are no pending requests for the ADU of p still active, then the request for the ADU of p 
that is already scheduled is exponentially backed off. When either a new request is scheduled or 
an existing request is backed-off, a request for the given ADU becomes pending with a back-off 
abstinence timeout equal to now + 2"°-!C3d;, where k is the round of the rescheduled request and 
d, = dist(sp). Finally, unless h is the source of p, SRM-RECy,, adds any trailing missing packets to 
the set to-be-requested, so that a request for each of them may subsequently be scheduled. 


Finally, in the case where p is a SESS packet, the process-mpkt,,(p) action does not affect the state 
of SRM-REC;; SESS packets are in effect discarded by the SRM-REC, automaton. 


Internal Actions Each internal action schdl-rqstp(s,i), for s € H,s # h,i € N, schedules a 
request for the packet (s,7). The precondition of the schdl-rqst,(s,7) action is that the host his a 
member of the reliable multicast group and the tuple (s,7) is in the set to-be-requested. The effects 
of the schdl-rqst;,(s,7) action are to schedule a new request for a point in time in the future that 
is chosen uniformly within the interval now + [Cid,, (Ci + C2)d,], with d, = dist(s), and to remove 
the tuple (s,7) from the set to-be-requested. 


Each internal action send-rqstpj(s,7), for s € H,i € N, models the expiration of the transmission 
timeout of a scheduled request for the packet (s,7). The precondition of send-rqst;(s,i) is 
that the host h is a member of the reliable multicast group and a previously scheduled request 
for the packet (s,7) has expired; that is, there is a tuple (s,i,t,k) in scheduled-rgqsts such that 
t = now. Let the tuple (s,7,t,k) be the element of scheduled-rqsts corresponding to the packet 
(s,7). send-rqst,(s,7) composes a request packet and adds it to the buffer msend-buff. The 
operation comp-rqst-pkt(h, (s,i)) composes a RQST packet from h for the packet (s, 7). 


Moreover, the request (s,7,t,k) is backed off and a request for the given ADU becomes pending. 
The timeout timer of the rescheduled request is set to a point it time in the future that is chosen 
uniformly within the interval now + 2**—"{Cyd,, (C1 + C2)d,] and the back-off abstinence timeout 
of the pending request is set to now + 2**-!C3d,, with k, = k +1 and d, = dist(s). 


Each internal action send-replp(s,i), for s € H,i € N, models the expiration of the transmission 
timeout of a scheduled reply for the packet (s,7). The precondition of send-replp(s,i) is that the 
host h is a member of the reliable multicast group and a previously scheduled reply for the packet 
(s,7) has expired; that is, there is a tuple (s,i,t,r) in scheduled-repls such that t = now. Let the 
tuple (s,i,t,1r) be the element of scheduled-repls corresponding to the packet (s,i). send-rep1;(s, 7) 
composes a reply packet and adds it to the buffer msend-buff. The operation comp-repl-pkt(h, p) 
composes a REPL packet from h for the packet p. 


Moreover, the tuple corresponding to (s,7) is removed from the set scheduled-repls and a tuple 
corresponding to (s,7) is added to the set pending-repls. The reply abstinence timeout of this 
pending reply is set to now + Dgdist(r). This pending reply prevents the scheduling of replies for 
the given ADU for D3dist(r) time units. 


Output Actions Each output action rm-recv,(p), for p € Prm-cunr, models the delivery of 
the packet p to the client. It is enabled when the host h is a member of the reliable multicast group 
and the packet p is the packet in the to-be-delivered buffer with the smallest sequence number. 
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Figure 15 The SRM-REc;, Automaton — Discrete Transitions (Cnt’d) 


input process-mpktp(p) input process-mpkt p,(p) 
where type(p) = DATA where type(p) = RQST 
eff if status = member then eff if status = member then 
(8p; tp) = td(p) (Sp; tp) = td(p) 
\\ Record foremost DATA packet \\ Only consider proper packets 
if h A sp) A min-seqno(sp) =1L then if min-seqno(sp) #-L Amin-seqno(sp) < tp then 


min-seqno(Sp) := ip; max-seqno(Sp) := ip 

\\ Only consider proper packets 

if min-seqno(sp) AL Amin-seqno(sp) < ip then 
\\ Archive and deliver packet 
if h A sp A (Sp, ip) ¢ archived-pkts? then 

archived-pkts U= {(strip(p), now) } 

if h £ sp then to-be-delivered U= { strip(p)} 
\\ Pkt need not be requested 
to-be-requested \= {(sp, tp) } 


\\ Cancel any scheduled requests and replies 


scheduled-rgsts \= {(sp, ip, t,k) | t € R2°,k © N} 
scheduled-repls \= {(sp, ip, t,r) | t € R2°,r € H} 
\\ Cancel any pending requests 
pending-rgsts \= {(8p, ip, t) |t € R2°} 
\\ Discover any trailing missing packets 
if h A sp) A maa-seqno(sp) < ip then 
to-be-requested U= 
{(sp,t) | 4 € N, maz-seqno(sp) <i < ip} 
Max-seqno(Sp) := ip 


if h # sp then 
if (sp,ip) € archived-pkts? then 
if (sp,ip) ¢ scheduled-repls? 
A(Sp, tp) € pending-repls? 
then 
\\ Schedule a new reply 
drep| := dist( sender (p)) 
trepl ‘© now + [Didrept, (Di + D2) drepi| 
rept 7= sender (p) 
scheduled-repls U= {( 8p, ip, trept, Trepl) } 
else 
if (sp,ip) ¢ scheduled-rgsts? then 
\\ Schedule a backed-off request 
ky := 2; dp := dist(sp) 
tr :€ now + 2¥r-lMCy dr, (Ci + C2)dr] 
scheduled-rgsts U= {(Sp, tp, tr, kr) } 
\\ Pkt request has been scheduled 
to-be-requested \= { (Sp, ip) } 
\\ A request becomes pending 


pending-rgsts \= {(8p, ip, tx) | tx € R29} 
tr := now + akr-1C3d, 
pending-rgsts U= {(Sp, ip, tr)} 


input process-mpkt p,(p) 


where type(p) = REPL 
eff if status = member then 


(8p, tp) = td(p) 

\\ Only consider proper packets 

if min-seqno(sp) AL Amin-seqno(sp) < ip then 
\\ A reply becomes pending 
pending-repls \= { (sp, ip, tx) | te € R2°} 
trepl 7= now + D3 dist(sp) 
pending-repls U= {(sp, tp; trept) } 
\\ Archive and deliver packet 
if h A sp A (Sp, ip) ¢ archived-pkts? then 

archived-pkts U= {(strip(p), now) } 

if h £ sp then to-be-delivered U= { strip(p)} 
\\ Pkt need not be requested 
to-be-requested \= {(Sp, ip) } 


\\ Cancel any scheduled requests and replies 


scheduled-rgsts \= {(8p, ip, t, k) | t € R2°,k € N} 
scheduled-repls \= {(Sp,tp,t,r) | t € R2°,r € H} 
\\ Cancel any pending requests 
pending-rgsts \= {(sp, ip, t) |t € R2°} 
\\ Discover any trailing missing packets 
if h A sp) A maz-seqno(sp) < ip then 
to-be-requested U= 
{(sp,t) | 4 € N, maz-seqno(sp) <i < ip} 
Max-seqno(Sp) := ip 


else 
if (sp,ip) ¢ pending-rgqsts? then 
\\ Backoff scheduled request 
choose t € R29°,k EN 
where (Sp, ip, t, k) € scheduled-rqsts 
scheduled-rqsts \= {(Sp, tp, t, k)} 
kp := k +1; dy := dist(sp) 
tr :€ now + 28r-1[Cyd,, (C1 + C2)dr] 
scheduled-rgqsts U= {(8p, ip, tr, kr)} 
\\ A request becomes pending 
pending-rgsts \= {(8p, tp, tx) | te € R29} 
tr := now + 2kr-1C3d, 
pending-rgqsts U= { (8p, tp, tr)} 
\\ Discover any trailing missing packets 
if h 4 sp A maz-seqno(sp) < ip then 
to-be-requested U= 
{(sp,t) |t EN, maz-seqno(sp) <i < ip} 
max-seqno(Sp) := ip 


input process-mpkt p,(p) 


where type(p) = SESS 


eff None 


This ordering constraint ensures that the foremost packet received of any source is delivered to the 
client prior to any other packet from the particular source. Its effects are to remove the packet p 
from the rm-recu-buff buffer. 


Each output action rec-msenda(p), for p € Psp, hands off the packet p from SRM-REC, to 
SRM-IPBUFFy, so that it may subsequently be multicast by SRM-IPBUFFy), using the underlying 
IP multicast service. The precondition of the rec-msend,;(p) action is that the host h is a member 
of the reliable multicast group and p is in the msend-buff buffer. Its effects are to remove p from 
the msend-buff buffer. 
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Time Passage The action v(t) models the passage of t time units. If the host h has crashed, 
then time is allowed to elapse. Otherwise, time is prevented from elapsing while either there are 
packets in the delivery and IP multicast transmission buffers or there are packets which have been 
declared missing but for which a request has yet to be scheduled; that is, while either the buffer 
to-be-delivered, the buffer msend-buff, or the set to-be-requested is non-empty. Furthermore, time 
is prevented from elapsing past the transmission deadline of any scheduled requests or replies. 


5.2.56 The Reporting Component — SRM-REP, 


The SRM-REP,, timed I/O automaton specifies the reporting component of the reliable multicast 
process at each host h € H. Figures 16, 17, and 18 present the signature, the variables, and the 
discrete transitions of SRM-REPy», respectively. 


Variables The variable now € R2° denotes the time that has elapsed since the beginning of 
an execution of SRM-REP,. The variable status captures the status of the host h. It evaluates 
to one of the following: idle, member, and crashed. While the host h has not crashed, we say 
that it is operational. The variable rep-deadline € R2°U denotes the point in time at which the 
next session packet is scheduled for transmission. The variable rep-deadline is equal to L when 
undefined. 


The variable dist-rprt(h’) € R=° x R=°U L, for each h’ € H,h' # h, records the transmission and 
the reception times of the most recent session packet of h’ to be received by the host h. That 
is, for each h’ € H, the variable dist-rprt(h’) is a tuple of the form (tsent,treva), Where tsent is 
the transmission time of the most recent session packet of h’ to be received by h and treyg is the 
reception time of this session packet by h. If the host h has not received a session packet from the 
host h’ since joining the reliable multicast group, then the variable dist-rprt(h’) is undefined; that 
is, dist-rprt(h’) =L. 

The variable dist(h’) € R=° x R°, for each h’ € H,h' # h, records the most up-to-date estimate of 
the distance from h to the host h’. Such distance estimates are ordered by the transmission time 
of the session packet of h that initiated their calculation; that is, a distance estimate calculated 
as a result of the transmission of a more recent session packet of h is considered more up-to- 
date. If two calculations are initiated by the same session packet of h, then the later calculation 
is considered more up-to-date. Thus, for each h’ € H, the variable dist(h’) is a tuple of the 
form (trprt,taist), Where trprt is the transmission time of the session packet of h that initiated the 
particular distance estimate calculation and tg; is the distance estimate obtained as a result of 
the particular calculation. 


The variable maz-seqno(h’) € N U 1, for each h’ € H,h’ 4 h, records the latest sequence number 
of h’ to have been observed by h. Recall that h may observe the transmission progress of other 
hosts by examining any type of packet. If the host h has not yet observed the transmission of any 
packets from the host h’, then the variable maz-seqno(h’) is undefined; that is, maz-seqno(h’) =. 


The variable dist-buff C H contains the hosts whose distance estimates have recently been updated 
but have not yet been reported to the SRM-REc,, automaton. Similarly, the variable seqno-buff 
contains the hosts whose maximum observed sequence numbers have recently been updated but 
have not yet been reported to the SRM-REC, automaton. 


Derived Variables The derived variable dist-rprt records the transmission and the reception 
times of the most recent session packet of all other hosts. dist-rprt is the set of tuples of the form 
(h’,ts,tr), with (t,,t-) = dist-rprt(h’), for h’ € H,h’ # h, and dist-rprt(h’) A. In effect, dist-rprt 
summarizes the information recorded by the dist-rprt(h’) variables, for all h’ € H,h' #h. 
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Figure 16 The SRM-REP;, Automaton — Signature 


Parameters: 


h € H,DFLT-DIST € R2°, SESS-PERIOD € Rt 


Actions: 
input time-passage 
crashp, v(t), for t € R2° 
rm-join-ackp, output 
rm-leavep rep-msend,(p), for p € Psp 
process-mpkt,(p), for p € Psp rep-dist,(h’,d’), for h’ C H,h’ £h,d € R2° 


rep-seqno,(s,i), forse Hs Ah ieNn 


Figure 17 The SRM-REpP;, Automaton — Variables 


Variables: 


now € R2°, initially now = 0 

status € SRM-Status, initially status = idle 

rep-deadline € R2°U LL, initially rep-deadline =L 

dist-rprt(h’) € R2° x R2°U L, for all h’ € H,h’ # h, initially dist-rprt(h’) =L 
dist(h’) € R2° x R2°, for all h’ € H,h’ #|h, initially dist(h’) = (0, DFLT-DIST) 
maz-seqno(h') € NU L, for all h’ € H,h’ #h, initially maz-seqno(h’) =L 
dist-buff C H, initially dist-buff = 0 

seqno-buff C H, initially seqno-buff = @ 


Derived Variables: 


dist-rprt = Un CH! ¢h, dist-rpre(h')zL Uh’, tsent, treva) ] dist-rprt(h’) = (tsent, treva) 
MAL-SEQnO = Un Hh! £h,maz-seqno(h')ZLA(R', maz-seqno(h’)) } 


The derived variable maz-seqno records the transmission progress of all other hosts. maz-seqno 
is the set of tuples of the form (h’, maz-seqno(h’)), for h’ € H,h’ #4 h, and maz-segno(h’) AL. 
In effect, maz-segno summarizes the information recorded by the maz-seqno(h’) variables, for all 
he H,h' Fh. 


Input Actions As in the case of the SRM-IPBUFF, and SRM-RECy, automata, the input action 
crash, models the crashing of the host h. The effects of the action crash, are to set the status 
variable to crashed, denoting that the host h has crashed. Once the host h has crashed, none of the 
input actions affect the state of SRM-REP», none of the internal and output actions are enabled, 
and time is not restricted from elapsing. 


The input action rm-join-ack, informs the SRM-REP, automaton that the host h has joined the 
reliable multicast group. If the host h is operational, then the rm-join-ack, action records the 
fact that the host h has joined the reliable multicast group by setting the variable status to member. 
Moreover, it schedules the transmission of a session packet no later than SESS-PERIOD time units 
in the future by setting the rep-deadline variable to a value that is uniformly chosen within the 
interval now + (0,SESS-PERIOD]. 


The input action rm-leave, informs the SRM-REP, automaton that the host h has left the reliable 
multicast group. If the host h is operational, then the action rm-leave, reinitializes all the variables 
of SRM-REP, except the variable now. 


The input action process-mpkt;,(p) processes the packet p. Recall that the functionality of the 
reporting component includes tracking the transmission progress of all sources and estimating the 
distance estimates from the host hf to all other reliable multicast group members. Provided the 
host h is a member of the reliable multicast group, the packet p is processed according to its packet 
type. 

We first consider the case where p is a SESS packet. Letting s, denote the sender of p, SRM-REP), 
checks whether p is either the first or the most recent session packet of sp to be received by h. If 
so, the variable dist-rprt(s,) is set to (time-sent(p), now) to record the reception of a more recent 
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session packet from the host sp. 


Then, if p is distance reporting for h and the session packet that initiated this report is at least 
as recent as the session packet that initiated the calculation of the current distance estimate to sp, 
then a new distance estimate to s, is calculated. If the calculation of the current distance estimate 
was initiated by the same session packet as the new calculation, then the new distance estimate is 
considered more recent since the latency observed from s, to h is more recent. SRM-REP» records 
the new distance estimate to s, by reassigning the tuple dist(s,). Furthermore, s, is added to 
the dist-buff buffer so that SRM-REP, may subsequently report to SRM-REC, the new distance 
estimate to Sp. 


Finally, SRM-REP;, goes through the transmission state reports contained in p to determine 
whether s, has observed further progress in the transmission of any of the sources; that is, 
whether s, has observed the transmission of later ADU packets by any of the sources. For 
each state report indicating further transmission progress, the corresponding maz-seqno variable 
is updated. Moreover, the respective source is added to the seqno-buff buffer so that SRM-REP;, 
may subsequently report this transmission progress of the respective source to SRM-RECp. 


We now consider the case where p is either a DATA, RQST, or REPL packet. Let s, and 7, denote the 
source and sequence number of the ADU packet contained in p. If the packet p is a DATA packet and 
is the first data packet to be received from s,, that is, if max-seqno(s,) =L, then maz-seqno(s,) is 
set to ip. If the packet p is either a DATA, RQST, or REPL packet and i, is greater than maz-seqno(sp), 
then maz-seqno(sp) is set to ip. 


Output Actions The output action rep-msend,(p), for p € Psrm, hands off the packet p to 
SRM-IPBUFF,, so that it may subsequently be multicast by SRM-IPBUFF, using the underlying 
IP multicast service. The precondition of the rep-msend,(p) action is that the host h is a member 
of the reliable multicast group, the variable now equals the session packet deadline rep-deadline, 
and the packet p corresponds to a session packet pertaining to the current state of the SRM-REP,, 
automaton. The operation comp-sess-pkt(h, now, dist-rprt, segno) composes the session packet p. 
rep-msend;,(p) schedules the transmission of the next session packet by setting the rep-deadline to 
SESS-PERIOD time units in the future. The parameter SESS-PERIOD of the SRM-REP, automaton 
specifies the period with which the host h transmits session packets. 


The output action rep-dist,,(h’,d’) reports to SRM-REC, the most recent distance estimate d’ to 
the host h’. The action rep-dist,(h’,d') is enabled when the host h is a member of the reliable 
multicast group, the distance estimate to h’ has recently been updated but has yet to be reported 
to SRM-RECp, that is, h’ € dist-buff, and the distance d’ is the most recent distance estimate to 
h’, that is, it is the distance component of the tuple dist(h’). The effects of rep-dist;,(h’,d’) are 
to remove the host h’ from the dist-buff buffer. 


The output action rep-seqnon(s,7) reports to SRM-REC, the most recent maximum sequence 
number observed for the source s. The action rep-seqno;(s,7) is enabled when the host h is 
a member of the reliable multicast group, the maximum sequence number for the source s has 
recently been updated but has yet to be reported to SRM-RECap, that is, s € seqno-buff, and 7 is 
the most recently recorded maximum sequence number for the source s, that is, i = maz-seqno(s). 
The effects of rep-seqno;(s,i) are to remove the source s from the segno-buff buffer. 


Time Passage The time passage action v(t) models the passage of t time units of time. If the 
host A has crashed, then time is allowed to elapse. Otherwise, time is allowed to elapse neither 
past the transmission of the next session packet, rep-deadline, nor while there are pending reports; 
that is, the reporting buffers dist-buff and seqno-buff are non-empty. 
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Figure 18 The SRM-REpP;, Automaton — Discrete Transitions 


input crash; 

eff status := crashed 

input rm-join-ack, 

eff if status #4 crashed then 


status := member 
rep-deadline :€ now + (0, SESS-PERIOD] 


input rm-leave, 


eff if status #4 crashed then 
Reinitialize all variables except now. 
input process-mpktp(p) 
where type(p) = SESS 
eff if status = member then 
Sp = sender(p) 
if dist-rprt(s,) =L then 
dist-rprt(sp) := (time-sent(p), now) 
else 
{tsent, treva) se dist-rprt(sp) 
if tsent < time-sent(p) then 
dist-rprt(sp) := (time-sent(p), now) 
if h € dist-rprt?(p) then 
(tsent, taelayed ) = dist-rprt(p, h) 
(trprt; taist) — dist(sp) 
if trprt < tsent then 
Uist ae (now “ai t delayed = tsent)/2 
dist(Sp) := (tsent, t/),,,) 
dist-buff U= {sp} 
foreach (h”’,i!’) € seqno-rprts(p) do: 
if maz-seqno(h”’) < i” then 
maz-seqno(h'’) := i!’ 
seqno-buff U= {h’’} 


input process-mpkt p,(p) 


where type(p) 4 SESS 
eff if status = member then 
(8p; tp) = td(p) 
if maz-seqno(sp) =L 
Atype(p) = DATA 
then 
maxz-seqno(Sp) := ip 
if maz-seqno(sp) AL 
Amax-seqno(sp) < tp 
then 
max-seqno(Sp) := ip 


output rep-msend; (p) 
pre status = member A now = rep-deadline 

Ap = comp-sess-pkt(h, now, dist-rprt, seqno) 
eff rep-deadline := now + SESS-PERIOD 
output rep-dist;(h’,d’) 
choose t/ € R2° 
pre status = member Ah’ € dist-buff A (t’,d’) = dist(h’) 
eff dist-buff \= {h'} 
output rep-seqno;(s, 2) 
pre status = member A s € seqno-buff \ i = maz-seqno(s) 
eff seqno-buff \= {s} 
time-passage v(t) 
pre status = crashed 

V (dist-buff = 0A seqno-buff = 0 

A(rep-deadline = Vnow +t < rep-deadline)) 

eff now := now +t 


Figure 19 The I[PMcaAstT Automaton — Signature 


Actions: 


input 

crash, forh € H 

mjoin,, forh € H 

mleave;,, for h € H 

msend;(p), for h € H,p € Prpmcast-Cuent 
internal 

mgrbg-coll(pkt), for pkt © Prpucasr 


output 
mjoin-ack,, for h € H 
mleave-ack;, for h € H 
mrecvp(p), for h € H,p © Pipmcast-Cuent 
mdrop(p, Hq), for p © Prpmcast-Curnt, Ha C A 
time-passage 
v(t), for t € R2° 


5.2.6 The IP Multicast Component — IPMCAST 


In this section, we give an abstract specification of the IP multicast service; the IP primitive that 
provides best-effort point to multi-point communication. In order to simplify the presentation, we 
assume that only a single multicast group exists. Furthermore, we abstract away the specifics of 
the underlying protocols that collectively provide the IP multicast service. In our model, hosts 
join, leave, and send data packets to the IP multicast group by issuing join and leave requests and 
by multicasting data packets, respectively. Following the initial service model of IP multicast, a 
host need not be a member of the IP multicast group to send messages addressed to the group. 
However, a host must join the IP multicast group in order to receive packets addressed to the IP 
multicast group. The IP multicast service guarantees that only hosts who are members of the IP 
multicast group actually receive IP multicast packets. 


Figures 19 and 20 present the signature, variables, and discrete transitions of the the IPMCAST 
timed I/O automaton; an abstract specification of the IP multicast service. 
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Variables The variable now € R2° denotes the time that has elapsed since the beginning of 
an execution of IPMcAsT. Each variable status(h) € IPmcast-Status, for h € H, denotes the IP 
multicast membership status of the host h. The value idle indicates that h is idle with respect to 
the IP multicast group; that is, it is neither a member, nor in the process of joining or leaving the 
IP multicast group. The value joining indicates that h is in the process of joining the IP multicast 
group; that is, the client has issued a request to join the IP multicast group and is awaiting an 
acknowledgment of this join request from the IP multicast service. The value leaving indicates 
that A is in the process of leaving the IP multicast group; that is, the client has issued a request to 
leave the IP multicast group and is awaiting an acknowledgment of this leave request from the IP 
multicast service. The value member indicates that h is a member of the IP multicast group. The 
value crashed indicates that h has crashed. When the host h has crashed, none of the input actions 
pertaining to h affect the state of IPMCAST and none of the locally controlled actions pertaining 
to h are enabled. While the host h has not crashed, we say that it is operational. 


The variable mpkts C Prpwcasr is comprised of the tuples that track the transmission progress of 
the packets transmitted during the particular execution of I[PMcAST. Of course, the size of the 
intended delivery set of each transmission progress tuple decreases monotonically as the hosts it 
consists of may leave the IP multicast group or crash. 


Derived Variables The derived variable up C 4 is the set of hosts that are operational; that is, 
the set of hosts that have not yet crashed. The derived variable idle C H is a set of hosts that are 
idle with respect to the IP multicast group. The derived variable joining C H is a set of hosts that 
are in the process of joining the IP multicast group. The derived variable leaving C H is a set of 
hosts that are in the process of leaving the IP multicast group. The derived variable members C H 
is a set of hosts that are members of the IP multicast group. 


Input Actions Each input action crashp,, for h € H, models the crashing of the host h. The 
crash, action records the fact that h has crashed by setting the status(h) variable to crashed. 
Moreover, the crash, action removes the host h from the intended delivery set of any packet in 
the set of pending packets mpkts. 


The input action mjoin, models the request of the client at A to join the IP multicast group. The 
mjoin, action is effective only while the host is idle with respect to the IP multicast group. When 
effective, the mjoinp, action sets the status(h) variable to joining so as to record that the host h 
has initiated the process of joining the IP multicast group. If the client is either a member of or in 
the process of joining the IP multicast group, then the mjoiny action is superfluous. If the client 
is already in the process of leaving the group, then the mjoin,;, action is discarded so as to allow 
the process of leaving the IP multicast group to complete. 


The input action mleave, models the request of the client at h to leave the IP multicast group. The 
mleave,, action is effective only while the host is either a member of or in the process of joining the 
IP multicast group. When effective, the mleave,, action sets the status(h) variable to leaving so 
as to record that the host h has initiated the process of leaving the IP multicast group. Moreover, 
the mleave,;, action removes the host h from the intended delivery set of any packet in the set of 
pending packets mpkts. Leave requests overrule join requests; that is, when a mleave,, action is 
performed while the host h is in the process of joining the IP multicast group, its effects are to 
abort the process of joining and to initiate the process of leaving the IP multicast group. If the 
client is either idle with respect to or already in the process of leaving the IP multicast group, then 
the mleave,, action is superfluous. 


The input action msend;,(p) models the transmission by the client at h of the packet p using the IP 
multicast service. The msend;,(p) action is effective only if the client is operational; recall that a 
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Figure 20 The IPMCAST automaton — Variables and Discrete Transitions 


Variables: 


Derived Variables: 


now € R2°, initially now = 0 

status(h) € IPmcast-Status, for all h € H, 
initially status(h) = idle, for allh € H 

mpkts C Prpycasr, initially mpkts = 0 


up = {h € H|status(h) # crashed} 

idle = {h € H|status(h) = idle} 
joining = {h € H|status(h) = joining} 
leaving = {h € H|status(h) = leaving} 
members = {h € H|status(h) = member} 


Discrete Transitions: 


input crash; 


eff if h € up then 
status(h) := crashed 
foreach pkt € mpkts do: 
intended(pkt) \= {h} 
input mjoin;, 
eff if h € idle then 
status(h) := joining 
input mleave, 
eff if h € joining U members then 
status(h) := leaving 
foreach pkt € mpkts do: 
intended(pkt) \= {h} 
input msend; (p) 


output mjoin-ack;, 
pre h € joining 

eff status(h) := member 
output mleave-acky, 
pre h € leaving 

eff status(h) := idle 
output mrecvz (p) 


choose pkt € Prpucasr 

pre h € members\ dropped(pkt) 
Apkt € mpkts \ p = strip(pkt) 

eff completed(pkt) U= {h} 


output mdrop(p, Hq) 


choose pkt € Prpucasr 
pre pkt € mpkts A p = strip(pkt) 


eff if h € up then AHqa © members\(completed(pkt) U dropped(pkt)) 
mpkts U= {(p, members, {h}, 0)} eff dropped(pkt) U= Ha 

internal mgrbg-coll(p) time-passage v(t) 

choose pkt € Pipycasr pre None 

pre pkt € mpkts A p = strip(pkt) eff now :=now+t 


Aintended(pkt) C (completed(pkt) U dropped(pkt)) 
eff = mpkts \= {pkt} 


client need not be a member of the IP multicast group to multicast packets using the IP multicast 
service. The effects of the msend;(p) action are to add a tuple corresponding to the transmission 
of the packet p to mpkts. This tuple is initialized as follows: its intended delivery set is initialized 
to the current members of the IP multicast group, its completed delivery set is initialized to the 
host A as if the packet p has already been delivered to the client at the host h, and its dropped set 
is initialized to the empty set. 


Output Actions The output action mjoin-ack,, acknowledges the join request of the client at h. 
The mjoin-ack, action is enabled only when the host is in the process of joining the IP multicast 
group. Its effects are to set the status(h) variable to member so as to indicate that the client at h 
has become a member of the IP multicast group. 


The output action mleave-ack;, acknowledges the leave request of the client at h. The action 
mleave-ack, is enabled when the host is in the process of leaving the IP multicast group. Its 
effects are to set the status(h) variable to idle so as to indicate that the client at h has become 
idle with respect to the IP multicast group. 


The output action mrecv,(p) models the delivery of the packet p to the client at h. The mrecvp(p) 
action is enabled when p is a pending packet, the host h is both a member of the IP multicast 
group and absent from the dropped set of the transmission progress tuple pkt in mpkts pertaining 
to p. The effects of the mrecv;(p) action are to add the host h to the completed delivery set of p’s 
transmission progress tuple pkt. 


The output action mdrop(p, Ha), for any p © Prpycast-Curnr and Hg C H, models the drop of the 
packet p on a link of the underlying IP multicast tree whose descendants are the hosts in the set Hg. 
The mdrop(p, Ha) action is enabled when p is a pending packet and Hg is comprised of members 
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of the IP multicast group for which the delivery of the packet p has neither completed, nor failed 
due to prior packet drops. The mdrop(p, Ha) action adds the hosts comprising Hg to the dropped 
set of the transmission progress tuple pkt in mpkts pertaining to p. 


Internal Actions The internal action mgrbg-coll(p) models the garbage collection of the packet 
p. A packet p may only be garbage collected after all the hosts comprising its intended delivery set 
either receive the packet or suffer a loss that prevents the packet from being forwarded to them. The 
effects of the mgrbg-col1l(p) action are to remove the transmission progress tuple pkt pertaining 
to p from the set mpkts. 


Time Passage The time-passage action v(t), for t € R=°, models the passage of ¢ time units. 
The action v(t) is enabled at any point in time and increments the variable now by t time units. 


Properties 


Lemma 5.1 (Transmission Integrity) For any timed trace 3 of IPMCAST, it is the case that 
any mrecv;(p) action, for h € H, in B is preceded in 3 by a msendy(p) action, for some h’ € H. 


Proof: Let a be any timed execution of IPMCAST such that 3 = ttrace(a). Consider a particular 
occurrence of an action mrecv,(p) in a, for h € H. Let (u,mrecv;(p),u’) € trans(IPMCAST) be 
the discrete transition in a corresponding to the particular occurrence of the action mrecv;,(p) in 
a. From the precondition of mrecv;(p), it is the case that there is a packet pkt € u.mpkts, such 
that p = strip(pkt). However, such a packet may be added to mpkts only by the occurrence of an 
action msendj,(p), for some h € H. It follows that the occurrence of any action mrecv;(p) in a is 
preceded by the occurrence of an action rm-sendj/(p), for some h’ € H. 


5.3 Constraints on RMI’s Parameters 


Figure 21 illustrates the behavior of RMI’s packet loss recovery scheme. In particular, for any 
k EN’, it depicts the transmission of a k-th round request by h, the scheduling of a k + 1-st round 
request by h, and the scheduling of a reply to h’s k-th round request by a host h’. ty, is the point in 
time at which h schedules its k-th round request, t}, is the point in time for which h schedules its 
k-th round request, tp is the point in time h’ receives h’s k-th round request, and t),, is the point 
in time for which h’ schedules its reply to h’s k-th round request. djs is half of h’s RTT estimate 
to the source s of the packet being recovered, dpjpyy and dy, are the actual transmission latencies 
between h and h’, and dyyp, is half of the RTT estimate of h’ to h. 


RMI must ensure that the back-off abstinence intervals do not overlap with request intervals. 
From Figure 21, this requirement is enforced by imposing the parameter constraint C3 < C}. 
Moreover, RMI must ensure that requestors schedule their retransmission requests such that they 
succeed the reception of replies pertaining to prior recovery rounds. Prematurely transmitting 
requests would result in wasteful recovery traffic. From Figure 21, this requirement corresponds 
to the satisfaction of the inequalities dppy + (Dy + Do)dyp tdin <2 Cid: fork] oN, 
Presuming that inter-host transmission latencies are fixed and symmetric and that RMI’s inter- 
host RTT estimates are accurate, these inequalities are satisfied if Dy + Dg +2 < 2C,. Finally, 
RMI must also ensure that a particular round’s requests are not discarded by potential repliers 
because they are received during the repliers’ abstinence periods pertaining to the prior recovery 
round. From Figure 21, this requirement corresponds to the satisfaction of the inequalities 
dpn! + (D1 + D2)dy,+D3dpip, < DOC die dah for k € Nt. Presuming that inter-host transmission 
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Figure 21 Timing Diagram of SRM’s Loss Recovery Scheme 
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latencies are fixed and symmetric and that RMI’s inter-host RTT estimates are accurate, these 
inequalities are satisfied if D, + Do + D3 < 2C\. 


The following assumption summarizes the constraints on RMI’s parameters. 


Assumption 5.1 RM/,’s parameters C1, C2, C3, D1, Do, and D3 satisfy the following constraints: 
C3 << Cy, Dy + Dg +2 < 2C), and Di + Dg + D3 < 2C\. 


To our knowledge, these constraints on SRM’s request /reply scheduling parameters, or even similar 
ones, have not been expressed to date. In fact, most analyses and simulations presume that no 
recovery packets are lost; that is, they presume that the initial recovery round is always successful. 
Our timing analysis illustrates that if the parameters are chosen arbitrarily it is possible to cause 
either superfluous requests and replies or the failure of a recovery round due to replier abstinence. 
Although in practice, due to inaccurate inter-host RTT estimates and varying and non-symmetric 
inter-host transmission latencies, superfluous traffic and/or recovery round failure may indeed be 
unavoidable, it is still important to realize their tie to SRM’s parameters. 


5.4 Safety and Liveness Analysis of RMI 


We begin this section by defining some history variables that facilitate the proof that RMI 
implements RMS. We then define a relation between the states of RMI and RMS and prove that 
this relation is indeed a timed forward simulation relation. This proof establishes that RMI is safe 
with respect to RMS; that is, it may only deliver appropriate packets to each member of the reliable 
multicast group. We conclude by showing that, under certain constraints, RMI is live with respect 
to RMS; that is, under the given constraints, RMI guarantees the timely delivery of the appropriate 
packets to the appropriate members of the reliable multicast group, as formalized in Section 4. 


5.4.1 History Variables 


Figure 22 introduces history and derived history variables for the automata SRM-REC, and SRM, 
respectively. 


The history variables of the SRM-REc;, automata, for h € H, are the variables trans-time(p), for 
all p © Pam-cunt{h], expected(h’) C H x N, for h’ € H, and delivered(h') C H x N, for h’ € H. 
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Figure 22 History and Derived History Variables 


History Variables of SRM-RECp: 


trans-time(p) € R2°U 1, for all p € Pay-cumnt[h], initially trans-time(p) =1, for all p € Pam-curnr|hl 
expected(h’) C H XN, for all h’ € H, initially expected(h’) = @, for all h’ € H 
delivered(h') C H xN, for all h’ € H, initially delivered(h’) = 0, for all h’ € H 

Derived History Variables of SRM: 


sent-pkts = {p © Pam-curnr | trans-time(p) £L} 

sent-pkts? = {(s,i) € H x N | dp € sent-pkts : id(p) = (s,i)} 

intended(p) = {h € H | id(p) € SRM-RECy,..expected(source(p))}, for all p © Pra-curnt 
completed(p) = {h € H | id(p) € SRM-RECy.delivered(source(p))}, for all p € Pay-curnr 
active-pkts = {p € Pra-curnr | p € sent-pkts A intended(p) N completed(p) # 0} 


Figure 23 SRM-REc,, History Variable Assignments 


input crash, input rm-send; (p) 
eff ... eff... 
foreach h’ € H do: \\ Record foremost DATA packet 
expected(h’) := 0 if min-seqno(sp) =L then 


delivered(h’) := 0 


input rm-leavey, expected(h) := suffix(p) 


eff if status 4 crashed then if max-seqno(Sp) =L 
Reinitialize all variables except now. Vip = maa-seqno(sp) +1 
foreach h’ € H do: then 
expected(h’) :=@ ea 
delivered(h') := 0 trans-time(p) := now 


delivered(h) U= {id(p)} 


output rm-recvp, (p) 


eff ... 
(Sp, tp) := td(p) 
if expected(sp) = 0 then 
expected(sp) := suffiz(p) 
delivered(sp,) U= {id(p)} 


Each trans-time(p) variable, for p € Pru-curnr(h], records the transmission time of the packet p 
by the host h. Each expected(h’) variable , for h’ € H, is comprised of the identifiers of the packets 
from h’ that the host h expects to deliver since it last joined the reliable multicast group. Each 
delivered(h') variable, for h’ € H, is comprised of the identifiers of the packets from h’ that the 
host h has already delivered since it last joined the reliable multicast group. Figure 23 specifies 
how the actions of SRM-REC, affect these history variables. 


The derived history variables of SRM are the set of identifiers of all packets sent since the beginning 
of the execution, sent-pkts, the intended delivery set of p, intended(p), for all p € Pau-cumnr, the 
completed delivery set of p, completed(p), for all p € Pra-cusnr, and the set of active packets, 
active-pkts. 


5.4.2 Preliminary Invariants and Lemmas 


In this section, we present several preliminary invariants and lemmas that are later used in the safety 
and liveness proofs of the RM; automaton. We begin by presenting several invariants pertaining 
to the SRM-REC, automaton, for h € H. 


Invariant 5.1 For h,h’ © H and any reachable state u of SRM-RECp, if u.status A member, then 
u.eapected(h’) = 0 and u.delivered(h’) = 0. 


Proof: Let a be any finite timed execution of SRM-REC, leading to u. The proof is by induction 
on the length n € N of a. For the base case, consider the finite timed execution a of length 0; that is, 
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a =u. Since u is a start state of SRM-RECa, it follows that u.status = idle, u.expected(h’) = 0, 
and u.delivered(h’) = (. Thus, the invariant assertion is satisfied in u. For the inductive step, 
consider a timed execution a of length k +1, for k ¢ N. Let a, be the prefix of a@ containing the 
first k steps of a and uz = ax.lstate. For the step from uz to u we consider only the actions that 
affect the variables status, expected(h’), and delivered(h’). 


O crashp,: the action crashp, sets the variable status to crashed and the variables expected (h’) 
and delivered(h’) to @. Thus, the invariant assertion is satisfied in u. 


O rm-join-ackp: if uz.status # crashed, then the action rm-join-acky, sets the variable status 
to member. Thus, the invariant assertion is satisfied in u. Otherwise, if u,.status = crashed, 
then the action rm-join-ack;, does not affect the state of SRM-REc,. Thus, the induction 
hypothesis implies that the invariant assertion is satisfied in wu. 


O rm-leave,: if uz.status # crashed, then the action rm-leavey, sets the variable status to idle 
and the expected(h') and delivered(h’) variables to 0. Thus, the invariant assertion is satisfied 
in u. Otherwise, if uz.status = crashed, then the action rm-leave, does not affect the state of 
SRM-REc;,. Thus, the induction hypothesis implies that the invariant assertion is satisfied in 
u. 


OG rm-send;(p), for p € Prw-curnr: first, consider the case where —(ux.status = member \ h = 
source(p)). In this case, rm-send,;,(p) does not affect the state of SRM-REC;,. Thus, the induction 
hypothesis implies that the invariant assertion holds in w. 


Second, consider the case where uz.status = member and h = source(p). Since ug.status = 
member and the rm-send,,(p) does not affect the status variable, it follows that u.status = member. 
Thus, the invariant assertion is satisfied in wu. 


O rm-recv,(p), for p € Pra-curnr: the precondition of the action rm-recv;(p) implies that 
uz. status = member. Since the rm-recv,;(p) does not affect the status variable, it follows that 
u.status = member. Thus, the invariant assertion is satisfied in u. 


Invariant 5.2 For h,h’ © H and any reachable state u of SRM-RECp, if u.min-seqno(h’) AL, 
then u.min-seqno(h') < u.maz-seqno(h’). 


Proof: Let a be any finite timed execution of SRM-REcy,, leading to u. The proof is by induction 
on the length n € N of a. For the base case, consider the finite timed execution a of length 0; that 
is, a = u. Since u is a start state of SRM-RECy), it follows that u.min-seqno(h) =L. Thus, the 
invariant assertion is satisfied in u. For the inductive step, consider a timed execution a of length 
k+1, fork € N. Let a, be the prefix of @ containing the first k steps of a and uz = az. Istate. 

For the step from uz to u we consider only the actions that affect the variables min-seqno(h’) and 

maz-seqno(h’). 

O rm-leavey: if uz.status # crashed, then the action rm-leave,, sets the variables min-seqno(h’) 
and maz-seqno(h’) to 1. Thus, the induction assertion is satisfied in u. Otherwise, if 
ux. status = crashed, then the action rm-leave,, does not affect the state of SRM-REC,. Thus, 
the induction hypothesis implies that the invariant assertion is satisfied in wu. 


O rm-send,(p), for p € Prm-curnr, such that source(p) = h’: letting (sp,ip) = id(p), we analyze 
the effects of rm-send,;(p) by cases. First, consider the case where 7(uxz.status = member A h = 
Sp). In this case, rm-send;,(p) does not affect the variables min-seqno(h’) and maz-seqno(h’). 
Thus, the induction hypothesis implies that the invariant assertion is satisfied in wu. 


Second, consider the case where u,.status = member and h = s8,. Since s, = h’, it follows 
that h = h’ = s,. If p is the foremost packet from s,, that is, u,.min-seqno(sp) =L, then 
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the rm-send;(p) action sets both min-seqno(h’) and masz-seqno(h’) to ip. It follows that 
u.min-seqno(h') < u.maz-seqno(h’). Thus, the invariant assertion is satisfied in u. 


If p is the next packet from s,, then the action rm-send;,(p) does not affect min-seqno(h’) and 
sets maz-seqno(h’) to ip; that is, u.min-seqno(h’) = uz.min-seqno(h’) and u.maz-seqno(h’) = 
Up.maz-seqno(h’) + 1. Since ip = uz.max-seqno(h’) + 1, it follows that ux.maz-segno(h’) < 
u.max-seqno(h’). The induction hypothesis implies that uz,.min-seqno(h’) < ugz.maz-seqno(h’). 
Thus, since it follows that u.min-seqno(h’) < u.maz-seqno(h’), as needed. 


If p is neither the foremost nor the next packet from s,, then the action rm-sendy(p) does not 
affect the variables min-seqno(h') and maz-seqno(h’). Thus, the induction hypothesis implies 
that the invariant assertion holds in wu. 


rep-seqno,(s,i), for s € H and i € N, such that s = h’: first, consider the case where 
7(ux.status = member / uz.min-seqno(s) AL Aup.maz-segno(s) < i). In this case, the action 
rep-seqno;(s,7) does not affect the state of SRM-REc;,,. Thus, the induction hypothesis implies 
that the invariant assertion holds in wu. 


Second, consider the case where ux.status = member A uz.min-seqno(s) AL Aug.maz-segno(s) < 
i. In this case, rep-seqnop(s, 7) does not affect min-seqno(h’) and sets maz-seqno(h’) to i; that is, 
u.min-seqno(h’) = uz.min-seqno(h’) and u.maz-seqno(h’) = i. Since uz.maz-seqno(h’) < i and 
u.maz-seqno(h’) = i, it follows that uz.maz-seqno(h') < u.maz-seqno(h’). From the induction 
hypothesis, it is the case that uz.min-seqno(h’) < uxz.max-seqno(h’). Thus, it follows that 
u.min-seqno(h') < u.maz-seqno(h’), as needed. 


process-mpkt;,(p), for p € Pgrm, such that source(p) = h’: letting (sp,ip) = id(p), we analyze 
the effects of process-mpkt;(p) by cases. First, if uz,.status 4 member, then process-mpkt,,(p) 
does not affect the state of SRM-RECa. Thus, the induction hypothesis implies that the invariant 
assertion holds in wu. 


Second, consider the case where u,.status = member. If p is the foremost packet from s,, that is, 
type(p) = DATA, h # sp, and uz.min-seqno(sp) =L, then the action process-mpktp(p) sets both 
min-seqno(h') and maz-seqno(h’) to ip. It follows that u.min-segno(h') < u.maz-seqno(h’), as 
needed. 


If p is not the foremost packet from s, but is proper, that is, uz.min-seqno(s,) AL and 
Up.min-seqno(S,) < ip, then the action process-mpkt,,(p) does not affect min-segno(h’) and 
may increase the value of maz-seqno(h’). It follows that u.min-seqno(h’) = ugz.min-seqno(h’) 
and uz.maz-seqno(h’) < u.maz-seqno(h’). From the induction hypothesis, it is the case that 
Up.min-seqno(h’) < uzp.maz-seqno(h’). Thus, it follows that u.min-segno(h') < u.maz-seqno(h’), 
as needed. 

Otherwise, if p is neither the foremost nor a proper packet from s,, then process-mpkt,(p) 


does not affect the variables min-seqno(h') and maz-seqno(h’). Thus, the induction hypothesis 
implies that the invariant assertion holds in u. 


Invariant 5.3 For h,h’ € H and any reachable state u of SRM-RECnp, if u.status = member, then 
it is the case that u.archived-pkts?(h') = u.delivered(h’) U u.to-be-delivered? (h’). 


Proof: Let a be any finite timed execution of SRM-REcy, leading to u. The proof is by induction 
on the length n € N of a. For the base case, consider the finite timed execution a of length 0; 
that is, a = u. Since u is a start state of SRM-RECa, it follows that u.status = idle. Thus, the 
invariant assertion holds in u. For the inductive step, consider a timed execution a of length k+1, 
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for k € N. Let a, be the prefix of a containing the first k steps of a and uz = agz.lstate. For the 
step from uz to u, we consider only the actions that affect the variables archived-pkts, delivered(h'), 
and to-be-delivered? (h’). 


a) 


0 


crash,: the action crash; sets the variable status to crashed. Thus, the invariant assertion 
holds in wu. 


rm-leave,: if uz.status # crashed, then the action rm-leave,, sets the variable status to idle. 
Thus, the invariant assertion holds in uw. 


Otherwise, if uz.status = crashed, then the action rm-leave;, does not affect the state of 
SRM-REC,,. It follows that u.status = crashed. Thus, the invariant assertion holds in uw. 


rm-send,(p), for p € Prw-cuent, such that source(p) = h’: letting (sp, ip) = id(p), we analyze 
the effects of rm-send,;(p) by cases. First, if =(u,.status = member A h = sp), then rm-send;(p) 
does not affect the state of SRM-REC,. Thus, the induction hypothesis implies that the invariant 
assertion holds in wu. 


Second, consider the case where ux.status = member /\ h = sp. If p is either the foremost or the 
next packet from h, then rm-send;,(p) archives p and records it as having been delivered. Thus, 
the induction hypothesis and the fact that the packet p is both archived and recorded as having 
been delivered imply that the invariant assertion holds in wu. 


Otherwise, if p is neither the foremost nor the next packet from h, then the action rm-send,(p) 
does not affect the variables archived-pkts?(h'), delivered(h'), and to-be-delivered?(h’). Thus, 
the induction hypothesis implies that the invariant assertion is satisfied in wu. 


rm-recv;(p), for p € Prw-cusnr, such that source(p) = h’: rm-send;(p) removes id(p) from 
to-be-delivered?(h’) and adds it to delivered(h'). Thus, the induction hypothesis implies that 
the invariant assertion holds in wu. 


process-mpkt,,(p), for p € Pspm, such that source(p) = h’: letting (sp,ip) = id(p), we analyze 
the effects of process-mpkt;,(p) by cases. First, if uz,.status 4 member, then rm-send,(p) does 
not affect the state of SRM-REc;,. Thus, the induction hypothesis implies that the invariant 
assertion holds in wu. 


Second, consider the case where u,z.status = member. We begin by considering the case 
where type(p) € {DATA,REPL}. In this case, consider the case where p is either the fore- 
most or a proper packet from s, and h # s,. In this case, if p has not already been 
archived, then process-mpktp(p) adds id(p) to both archived-pkts?(h’) and to-be-delivered?(h’). 
This fact and the induction hypothesis imply that the invariant assertion is satisfied in 
u. Otherwise, if p has already been archived, then process-mpkt;(p) adds id(p) to 
to-be-delivered?(h') only. Since id(p) € uz.archived-pkts?(h') and process-mpktp(p) does not af- 
fect archived-pkts, it follows that u.archived-pkts? (h’) = uz.archived-pkts?(h’) and, thus, id(p) € 
u.archived-pkts?(h'). Moreover, since process-mpkt;,(p) adds id(p) to to-be-delivered?(h’), it 
follows that u.to-be-delivered?(h') = uz.to-be-delivered?(h’) U {id(p)}. From the induction hy- 
pothesis, it is the case that ux.archived-pkts?(h') = ug.delivered(h’) U uz.to-be-delivered?(h’). 
Since process-mpkt;,(p) does not affect delivered(h’), it follows that the invariant assertion 
holds in wu. 


Otherwise, if either p is neither the foremost nor a proper packet from s, or h = 8p, 
process-mpkt;(p) does not affect archived-pkts?(h'), delivered(h’), and to-be-delivered?(h’). 
Thus, the induction hypothesis implies that the invariant assertion is satisfied in wu. 

If type(p) € {RQST, SESS}, then the action process-mpkt;,(p) does not affect archived-pkts?(h’), 
delivered(h’), and to-be-delivered? (h'). Thus, the induction hypothesis implies that the invariant 
assertion is satisfied in wu. 
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Invariant 5.4 For h,h'’ € H and any reachable state u of SRM-REC;), it is the case that 
u.archived-pkts?(h') C u.window?(h’). 


Proof: Let a be any finite timed execution of SRM-REcy,, leading to u. The proof is by induction 
on the length n € N of a. For the base case, consider the finite timed execution a of length 0; 
that is, a = u. Since u is a start state of SRM-RECp, it is the case that u.min-segno(h’) =1 and 
u.archived-pkts?(h’) = 0. Since u.min-seqno(h’) =, it is the case that u.window?(h’) = 0. Thus, 
it follows that u.archived-pkts?(h') C u.window?(h’), as needed. For the inductive step, consider a 
timed execution a of length k+ 1, for k € N. Let a, be the prefix of a containing the first k steps 
of a and uz = ag.lstate. For the step from uz to u we consider only the actions that affect the 
variables min-seqno(h’), max-seqno(h’), and archived-pkts? (h’). 


O rm-leaven,: if uz.status #~ crashed, then the action rm-leavey, reinitializes all the variables 
of SRM-REC;, except the variable now. Thus, it is the case that u.min-segno(h’) =L and 
u.archived-pkts?(h') = 0. Since u.min-seqno(h’) =1, it is the case that u.window?(h’) = 0. 
Thus, it follows that u.archived-pkts?(h’) C u.window?(h’), as needed. 


Otherwise, if uz.status = crashed, then the action rm-leave,, does not affect the state of 
SRM-REc,,. Thus, the induction hypothesis implies that the invariant assertion holds in uw. 


O rm-send,(p), for p € Pro-cumnr, such that source(p) = h’: letting (sp,ip) = id(p), we analyze 
the effects of rm-send,;(p) by cases. First, consider the case where =(ux.status = member A h = 
Sp). In this case, rm-send;,(p) does not affect the variables min-seqno(h’) and maz-seqno(h’). 
Thus, the induction hypothesis implies that the invariant assertion is satisfied in wu. 


Second, consider the case where ux,.status = member and h = s,. Since s, = h’, it follows 
that h = h’ = sy. If p is the foremost packet from sp, that is, uz.min-seqno(sp) =L, then 
the rm-send;(p) action sets both min-seqno(s,) and maz-seqno(sp) to i, and adds the element 
(p,now) to archived-pkts. Since uz,.min-seqno(sp) =L, it is the case that u,.window?(h') = 
(. Thus, the induction hypothesis implies that uz.archived-pkts?(h') = Q. It follows that 
u.archived-pkts?(h') = {id(p)}. Moreover, since u.min-segno(h') = u.maz-seqno(h’) = ip, 
it follows that ug.window?(h') = {id(p)}. Thus, if follows that u.archived-pkts?(h’) C 
u.window?(h’), as needed. 


If p is the next packet from sp, that is, up.min-seqno(sp) AL and ip = ux.maz-segno(sp) + 1, 
then rm-send;(p) sets maz-seqno(s,) to it) and adds the element (p,now) to 
archived-pkts. It follows that w.archived-pkts?(h') =  ug.archived-pkts?(h') U {id(p)} 
and u.window?(h') = upz.window?(h') U {id(p)}. From the induction hypothesis, 
it is the case that ug.archived-pkts?(h’) C uz-window?(h’'). Thus, it follows that 
u.archived-pkts?(h') C u.window?(h’), as needed. 


O process-mpkt,,(p), for p € Pspm, such that type(p) € {DATA, REPL} and source(p) = h’: letting 
(Sp, tp) = id(p), we analyze the effects of process-mpktp(p) by cases. 


First, consider the case where p is the foremost packet from s,; that is, type(p) = DATA, 
h A Spy, and up.min-seqno(sp) =L. Since uxz.min-segno(sp) =, it is the case that 
Up-window? (sp) = 0. Thus, the induction hypothesis implies that u,.archived-pkts?(sp) = 0. 
Since process-mpkt;,(p) sets both variables min-segqno(h’) and maz-seqno(h’) to ip and adds 
(strip(p), now) to archived-pkts, it follows that u.archived-pkts?(h') = u.window?(s,) = {id(p)}. 
Thus, it follows that u.archived-pkts?(h’) C u.window?(h’). 


Second, consider the case where p is not the foremost packet from s, but is proper; that. is, 
Up.-Min-seqno(S,) AL and uz.min-seqno(sp) < ip. In this case, the process-mpkt,,(p) action: 
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i) adds the element (strip(p), now) to archived-pkts, if h # 8) \ (Sp, ip) ¢ Up-archived-pkts?, and 
ii) sets max-seqno(s,) to ip, if up.max-seqno(sp) < ip. It follows that u.archived-pkts?(sp)) C 
Uz. archived-pkts ?(s,)U {id(p)} and uz.window? (sp) U{id(p)} C u.window?(s,). Moreover, from 
the induction hypothesis, it is the case that u,.archived-pkts?(h’) C uz.window?(h’). Thus, it 
follows that u.archived-pkts?(h') C u.window? (h’), as needed. 


Invariant 5.5 For h © AH, p © Pryu-cuent, and any reachable state u of SRM-RECp, if p € 
u.to-be-delivered, then u.min-seqno(source(p)) AL and u.min-seqno(source(p)) < seqno(p). 


Proof: From the effects of the process-mpkt,(p) action, for h € H and p € Pgpm, such that 
id(p) = (Sp, tp), it follows that a packet p may be added to to-be-delivered only if h is not the source 
of p and p is a proper packet; that is, h # 8), min-seqno(s,) AL, and min-segno(sp) < ip. |_| 


Invariant 5.6 For h,h’ © H and any reachable state u of SRM-RECh, it is the case that: 
1. u.min-seqno(h’) =1= u.exrpected(h’) = 0, 
2. u.delivered(h’) C u.expected(h’), 
3. h=h' Au.status #4 crashed => u.expected(h’) = u.proper?(h'), and 
4. u.expected(h') 4 —) = u.expected(h’) = u.proper? (h’) 


Proof: Let a be any finite timed execution of SRM-REcy,, leading to u. The proof is by induction 
on the length n € N of a. For the base case, consider the finite timed execution a of length 0; 
that is, a = u. Since uw is a start state of SRM-RECa, it is the case that u.min-seqno(h’) =L, 
u.delivered(h') = Q, u.expected(h') = (, and u.proper?(h') = @. Thus, the invariant assertion is 
satisfied in u. For the inductive step, consider a timed execution a of length k +1, for k € N. Let 
az be the prefix of @ containing the first k steps of a and uz = ax.lstate. For the step from uz to 
u we consider only the actions that affect the variables min-seqno(h’), delivered(h’), expected(h'), 
and proper? (h’). 

O crashp: the crash, action sets delivered(h’) and expected(h') to 0. Thus, the invariant assertion 

is satisfied in wu. 


O rm-leave;,: if uz.status # crashed, then the action rm-leavey reinitializes all the variables of 
SRM-RECy, except the variable now and sets the variables delivered(h’) and expected(h’) to 0. It 
follows that u.min-segno(h’) =, u.delivered(h') = 0, u.expected(h') = 0, and u.proper?(h’) = 0. 
Thus, the invariant assertion is satisfied in wu. 

Otherwise, if uz.status = crashed, then the action rm-leave;, does not affect the state of 


SRM-REc;,. Thus, the induction hypothesis implies that the invariant assertion is satisfied in 
u. 


O rm-send,(p), for p € Pra-cumnt, such that source(p) = h’: letting (sp,ip) = id(p), we analyze 
the effects of rm-recvp(p) by cases. First, if =(u,.status = member \ h = sy), then rm-send),,(p) 
does not affect the state of SRM-REC,. Thus, the induction hypothesis implies that the invariant 
assertion holds in wu. 


Second, consider the case where uxz.status = member \ h = sy. If p is the foremost packet to 
be transmitted by s,; that is, uz.min-seqno(sp,) =, then rm-send;(p) sets min-seqno(h’) to ip, 
sets expected(h') to suffiz(p), and adds id(p) to delivered(h'). The induction hypothesis and the 
fact that u,.min-seqno(s,) =L imply that uz.expected(s,) = 0. Moreover, from the induction 
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hypothesis it is the case that u,.delivered(sp) C ux.expected(sp). Since uz.expected(sp) = 0, 
it follows that u,.delivered(sp) = 0. Thus, from the effects of rm-send;(p), it follows that 
u.expected(sp) = suffiz(p) and u.delivered(s,) = {id(p)}. Since id(p) € suffix(p), it follows 
that u.delivered(h’) C u.expected(h’). Moreover, since u.proper?(h’) = suffix(p), it follows that 
u.expected(h’) = u.proper?(h’). Since u.min-seqno(sp) = ip, u.delivered(h’) C u.expected(h’), 
and u.expected(h’) = u.proper?(h’), it follows that the invariant assertion is satisfied in u. 


If p is the next packet from s,, that is, ug.min-seqno(s,) AL and i, = uz.max-seqno(sp) + 1, 
then rm-send,(p) does not affect min-seqno(h’), sets maz-seqno(h’) to ip, and adds id(p) 
to delivered(h’); that is, u.min-seqno(s,) = Uug.min-seqno(sp), u.max-seqno(S,) = tp, and 
u.delivered(sp) = uz.delivered(s,) U {id(p)}. 


Since h = h’ A uxz.status # crashed, the induction hypothesis implies that uz.expected(h’) = 
Uz. proper? (h’). Since rm-send;(p) affects neither min-seqno(h’) nor expected(h’), it follows that 
u.proper?(h') = up.proper?(h’) and u.expected(h') = uz.expected(h’). Thus, it follows that 
u.expected(h’) = u.proper?(h’), as needed. 


From the induction hypothesis, it is the case that ux.delivered(h’) C up,.expected(h’). 
Since ip = Ug.maz-seqno(sp) + 1 and u.maz-seqno(s,) = itp, it is the case that 
Up.maz-seqno(Sp,) < u.max-seqno(s,). Thus, Invariant 5.2 implies that up.min-seqno(sp) < ip. 
Since uxz.min-seqno(Sp) < tp, it follows that id(p) ©  ug.proper?(h’). Since 
uz-expected(h’) = uz.proper?(h’), it follows that id(p) ©  upg.expected(h’). Since 
u.delivered(s)) =  wg.delivered(s,) U {id(p)},  ug.delivered(h’) C — ug.expected(h’), 
id(p) ©  w,.expected(h’), and u.expected(h’) =  ug.expected(h’), it follows that 
u.delivered(h') C u.expected(h’). Since u.min-seqno(sp) AL, u.delivered(h’) C u.expected(h’), 
and u.expected(h’) = u.proper?(h’), it follows that the invariant assertion is satisfied in u. 


rm-recv;,(p), for p € Pam-curnr, such that source(p) = h’: letting (sp,ip) = id(p), we analyze 
the effects of rm-recv;,(p) by cases. First, consider the case where uz.expected(h’) = 0. From 
the induction hypothesis, it is the case that u,.delivered(h') C upz.expected(h'). Thus, it follows 
that uxz.delivered(h’) = 0. Since uxz.expected(h’) = 0, rm-recvp(p) sets expected(h’) to suffix(p) 
and adds id(p) to delivered(h’); that is, u.expected(sp) = suffiz(p) and u.delivered(sp) = {id(p)}. 
Since id(p) € suffix(p), it follows that u.delivered(h') C u.expected(h’), as needed. 


Since upz.delivered(h’) = @, Invariant 5.3 implies that ug.archived-pkts?(h') = 
ux. to-be-delivered?(h'). From the precondition of rm-recvp(p), it follows that p is h’s foremost 
packet from h’; that is, 7, = uz.min-seqno(h’). Since suffix(p) = {(s,1) € HxN | 8) = sip < +}, 
it follows that u.proper?(h’) = suffix(p). Thus, it follows that u.erpected(h') = u.proper?(h’), 
as needed. 


Finally, since p € ux.to-be-delivered, Invariant 5.5 implies that u,z.min-seqno(sp) AL. Since 
rm-recv;,(p) does not affect min-seqno(sp), it follows that u.min-seqno(sp) #L. Since 
u.min-seqno(s») #L, u.delivered(h’) C u.expected(h’), and u.expected(h’) = u.proper?(h’), it 
follows that the invariant assertion is satisfied in wu. 


Second, consider the case where u,.expected(h’) # @. In this case, rm-recv;(p) does not 
affect min-seqno(sp), does not affect expected(h’), and adds id(p) to delivered(h'); that is, 
u.proper?(h') = ug.proper?(h'), u.expected(s»)) = Up-expected(s,), and u.delivered(s,) = 
ux. delivered(s,) U {id(p)}. Since ux.expected(h’) # 0, the induction hypothesis implies that 
Up-expected(h’) = ux.proper?(h’). Since u.proper?(h') = ug.proper?(h'), u.expected(s,) = 
ug. expected(s,), it follows that u.expected(h’) = u.proper?(h’), as needed. 

Since p € ux.to-be-delivered, Invariant 5.3 implies that id(p) € ug-.archived-pkts?(h'). Thus, 


Invariant 5.4 implies that id(p) € uz.window?(h’). By definition it follows that window? (h’) 
proper?(h’). Thus, it is the case that id(p) € ugx.proper?(h’) and, since u.proper?(h’) = 
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Up-proper?(h'), id(p) € u.proper?(h’). Thus, it follows that u.delivered(s,) C u.expected(s,), 
as needed. 


Finally, since p € ux.to-be-delivered, Invariant 5.5 implies that u,.min-seqno(sp) AL. Since 
rm-recvp(p) does not affect min-seqno(sp), it follows that u.min-seqno(sp) AL. Since it is 
the case that u.min-seqno(s,) AL, u.delivered(h’) C u.expected(h’), and u.expected(h’) = 
u.proper?(h’), it follows that the invariant assertion is satisfied in u. 


process-mpkt,,(p), for p € Pspm, such that source(p) = h’: letting (s»,%)) = id(p), we analyze 
the effects of process-mpkt,,(p) by cases. 


First, if type(p) = DATA, ux.status = member, h # sy, and uxz.min-seqno(h') =L, then the action 
process-mpkt,,(p) sets min-seqno(h’) to i, and affects neither delivered(h') nor expected(h’). 
Since uz.min-seqno(h’) = 1, the induction hypothesis implies that u,.expected(h’) = 0. More- 
over, from the induction hypothesis, it is the case that uxz.delivered(h') C uz.expected(h’). Thus, 
since uz.expected(h') = 0), it follows that ux.delivered(h’) = 9. Since process-mpkt;,(p) affects 
neither delivered(h’) nor expected(h’), it follows that u.delivered(h’) = ( and u.expected(h’) = 0. 
Thus, it follows that u.delivered(h') C u.expected(h’), as needed. Since h ¥ sy, and sp = h’, it 
follows that h 4 h’. Thus, since u.min-seqno(h') £1, u.delivered(h') C u.expected(h’), h # h’, 
u.expected(h’) = 0, it follows that the invariant assertion is satisfied in u. 


Otherwise, process-mpkt;(p) does not affect min-seqno(h’), delivered(h'), and expected(h’). 
Thus, the induction hypothesis implies that the invariant assertion holds in wu. 


Invariant 5.7 Let h © H and u be any reachable state u of SRM-REC,. For any p © Psrm, such 
that type(p) € {DATA, REPL} and p € u.msend-buff, it is the case that id(p) € u.archived-pkts? . 


Proof: Let a be any finite timed execution of SRM-REcy,, leading to u. The proof is by induction 
on the length n € N of a. For the base case, consider the finite timed execution a of length 0; that 


is, 


a =u. Since u is a start state of SRM-RECp, it is the case that u.msend-buff = 0. Thus, the 


invariant assertion is trivially satisfied in u. For the inductive step, consider a timed execution a of 
length k+1, for k € N. Let ax be the prefix of a containing the first & steps of a and uz = ax. lstate. 
For the step from uz, to u we consider only the actions that affect the variables msend-buff and 
archived-pkts. 


a) 


0 


rm-leave,: the action rm-leave,, initializes the variables msend-buff and archived-pkts. Thus, 
the invariant assertion holds in wu. 


rm-send,(p), for p € Prm-curnr: the action rm-send;(p) adds the packet comp-data-pkt(p) to 
msend-buff if and only if it adds the element (p, now) to the variable archived-pkts. This fact 
and the induction hypothesis imply that the invariant assertion holds in wu. 


send-repl;(s,7), for s € H andi € N: the action send-replp,(s,i) adds the packet pkt = 
comp-repl-pkt(h,p), for p € Pru-cuwr,t € R2°, such that (p,t) € archived-pkts, and id(p) = 
(s,i) to msend-buff. Since id(pkt) € u,z.archived-pkts? and the send-repl;(s,i) action does 
not affect the variable archived-pkts, it follows that id(pkt) € u.archived-pkts?. The induction 
hypothesis and the facts that pkt € u.msend-buff and id(pkt) € u.archived-pkts? imply that the 
invariant assertion is satisfied in u. 


process-mpkt;(p), for p € Pgrm, such that source(p) = h’: process-mpktp(p) does not 
affect msend-buff and may only add the element id(p) to archived-pkts?. Thus, the induction 
hypothesis implies that the invariant assertion holds in wu. 
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Invariant 5.8 For h © H, p © Pryu-curnt, and any reachable state u of SRM-RECap, if p € 
u.to-be-delivered, then source(p) # h. 


Proof: From the effects of the process-mpkt;,(p) action, for h € H and p € Pgpm, it follows that 
a packet p may be added to to-be-delivered only if source(p) 4 h. | 


Invariant 5.9 For h,h' € H and any reachable state u of SRM-RECp, if u.expected(h’) 4 0, then 
u.to-be-delivered?(h’) C u.expected(h’). 


Proof: Suppose that u.expected(h’) 4 0. Invariant 5.1 implies that u.status = member. Moreover, 
Invariant 5.6 implies that u.expected(h’) = u.proper?(h’). From Invariant 5.4, it is the case that 
u.archived-pkts?(h') C u.window?(h'). Moreover, since u.status = member, Invariant 5.3 implies 
that u.to-be-delivered?(h') C u.window?(h’). Since by definition u.window?(h’) C u.proper?(h’), it 
follows that u.to-be-delivered?(h’) C u.proper?(h’). Finally, since u.expected(h') = u.proper?(h’), 
it follows that u.to-be-delivered?(h’) C u.expected(h’). a 


Invariant 5.10 For h,h’ € H and any reachable state u of SRM-REC;, it is the case that 
u.to-be-requested(h’) C u.window? (h’). 


Proof: Let a be any finite timed execution of SRM-REcy,, leading to u. The proof is by induction 
on the length n € N of a. For the base case, consider the finite timed execution a of length 0; 
that is, a = u. Since wu is a start state of SRM-RECy,, it follows that u.min-seqno(h’) =1 and 
u.to-be-requested(h’) = (. Thus, the invariant assertion is satisfied in u. For the inductive step, 
consider a timed execution a of length k+ 1, for k ¢ N. Let a, be the prefix of a@ containing the 
first & steps of a and uz = ax.lstate. For the step from uz to u we consider only the actions that 
affect the variables min-seqno(h’), maz-seqno(h’), and to-be-requested(h’). 


O rm-leavey,: if uz.status = crashed, then rm-leave, does not affect the state of RM-CLIENTa,. 
Thus, the induction hypothesis implies that the invariant assertion is satisfied in u. Otherwise, 
if u,.status # crashed, then rm-leavey, reinitializes all the variables of SRM-REC, except the 
variable now. It follows that u.min-seqno(h’) =L and u.to-be-requested(h’) = §. Thus, the 
invariant assertion holds in uw. 


O rm-send,(p), for p € Prw-cuent, such that source(p) = h’: letting (sp, ip) = id(p), we analyze 
the effects of rm-send;(p) by cases. First, if =(u,.status = member A h = sy), then rm-send),(p) 
does not affect the state of RM-CLIENT;,. Thus, the induction hypothesis implies that the 
invariant assertion is satisfied in wu. 


Second, consider the case where ux.status = member \h = sy. If ug.min-seqno(h’) =, 
then rm-send;(p) sets min-seqno(h’) and maz-segno(h’) to ip. Since ug.min-segno(h’) =L, 
it follows that uz.window?(h') = 90. Thus, the induction hypothesis implies that 


ug.to-be-requested(h') = ). Since rm-send;,(p) does not affect the variable to-be-requested, it 
follows that u.to-be-requested(h’) = . Thus, the invariant assertion holds in wu. 


Otherwise, if uz.min-seqno(h’) #1, then rm-send;,(p) may only increase the value of the vari- 
able maz-seqno(h’) and does not affect the variable to-be-requested; that is, uzp.window? (h’) C 
u.window?(h’) and u.to-be-requested(h’) = uz.to-be-requested(h’). Thus, the induction hypothe- 
sis implies that the invariant assertion holds in wu. 


Oj rep-seqno,(s,i), for s € H, s # h andi € N, such that s = h’: first, if a(ug.status = 
member /\ uz,.min-segno(s) AL Aug.maz-seqno(s) < i), then rep-seqnon(s,7) does not affect the 
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state of SRM-REc,. Thus, the induction hypothesis implies that the invariant assertion holds 
in u. 

Otherwise, if uz.status = member, uz.min-seqno(s) AL, and uz.maz-seqno(s) < i, then the 
action rep-seqno,(s,i) adds {(s,2’) | i’ © N,ug.maz-seqno(s) < i’ < i} to to-be-requested 
and sets maz-seqno(s) to 7. Invariant 5.2 and the fact that uz.maz-segno(s) < i imply that 
Uz.min-seqno(s) < i. Since rep-seqnon(s,7) does not affect the variable min-seqno(s), it follows 
that u.min-seqno(s) < i. Thus, since u.min-seqno(s) < i and u.maz-seqno(s) = 1, it follows 
that {(s,7’) | 7” © N,up.maz-seqno(s) < i’ < i} C u.window(h’). This fact and the induction 
hypothesis imply that u.to-be-requested(h’) C u.window? (h’). 


schdl-rqstp(s,i), for s € H andi € N, such that s = h’: the action schdl-rqst;/(s, i) 
removes the element (s,i) from the set u,.to-be-requested and does not affect min-seqno(h’) 
and maz-seqno(h’). Thus, the induction hypothesis implies that the invariant assertion holds in 
U. 


process-mpkt;(p), for p € Pgrm, such that type(p) = DATA and source(p) = h’: letting 
(Sp,tp) = id(p), we analyze the effects of the process-mpkt;,(p) action by cases. First, if 
uz. status # member, then process-mpkt,,(p) does not affect the state of SRM-REC,. Thus, the 
induction hypothesis implies that the invariant assertion holds in u. 


Second, consider the case where u,.status = member. If h £ s, and uz.min-seqno(s,) =L, then 
process-mpkt,,(p) sets the variables min-seqno(h’) and maz-seqno(h’) to ip and does not affect 
the variable to-be-requested. Since uz.min-seqno(h’) =, it follows that uz.window?(h’) = 0. 
Thus, the induction hypothesis implies that u,.to-be-requested(h') = 0. Since process-mpktp(p) 
does not affect the variable to-be-requested, it follows that u.to-be-requested(h') = . Thus, the 
invariant assertion holds in wu. 


If uz.min-seqno(sp) AL, uz.min-seqno(sp) < ip, h A Sp, and uz.max-seqno(sp) < tp, then the 
action process-mpktp(p) adds {(sp,7) | 1 € N,ug.maz-seqno(sp) < i < ip} to to-be-requested 
and sets maz-seqno(h’) to ip. Since uz.min-seqno(h’) < i, and process-mpkt,,(p) does not affect 
the variable min-seqno(h’), it follows that u.min-seqno(h’) < ip. Since u.min-seqno(h’) < i and 
u.maz-seqno(h') = i, it follows that {(sp,7) | i € N, up.maa-seqno(sp) <i < ip} C u.window(h’). 
This fact and the induction hypothesis imply that u.to-be-requested(h’) C u.window? (h’). 

Otherwise, process-mpkt;,(p) does not affect the variables min-seqno(h'), maz-seqno(h’), and 


to-be-requested(h’). Thus, the induction hypothesis implies that the invariant assertion holds in 
u. 


process-mpkt;,(p), for p € Psp, such that type(p) € {REPL, RQST} and source(p) = h’: letting 
(Sp,tp) = id(p), we analyze the effects of the process-mpkt;,(p) action by cases. First, if 
uz. status # member, then process-mpkt,;,(p) does not affect the state of SRM-RECp;. Thus, the 
induction hypothesis implies that the invariant assertion holds in u. 


Second, consider the case where u,.status = member. If it is the case that uz,.min-seqno(s,) AL, 
UK-Min-seqno(Sp) < ip, h F Sp, and ugz.maz-seqno(sp) < ip, then the action process-mpktp(p) 
adds {(5,,7) | i € N, ug.maz-seqno(sp) < i < ip} to to-be-requested and sets maz-seqno(h’) to ip. 
Since u,.min-seqno(h') < ip and process-mpktp(p) does not affect the variable min-segno(h’), 
it follows that u.min-seqno(h’) < i». Thus, since u.min-segno(h’) <i and u.maz-segno(h’) = i, 
it follows that {(s,,i) | i € N,ug.maz-seqno(sp) < i < ip} C u.window(h’). This fact and the 
induction hypothesis imply that w.to-be-requested(h’) C u.window? (h’). 


Otherwise, process-mpkt;,(p) does not affect the variables min-seqno(h'), max-seqno(h’), and 
to-be-requested(h'). Thus, the induction hypothesis implies that the invariant assertion holds in 
U. 
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Invariant 5.11 For h,h’ € H and any reachable state u of SRM-REC;, it is the case that 
u.scheduled-rqsts?(h’) C u.window? (h’). 


Proof: Let a be any finite timed execution of SRM-REc,, leading to u. The proof is by induction 
on the length n € N of a. For the base case, consider the finite timed execution a of length 0; 
that is, a = u. Since wu is a start state of SRM-REC»p, it follows that u.min-seqno(h’) =1 and 
u.scheduled-rqsts?(h') = 0. Thus, the invariant assertion is satisfied in u. For the inductive step, 
consider a timed execution a of length k+ 1, for k € N. Let ax be the prefix of a@ containing the 
first & steps of a and uz = ay. lstate. For the step from uz to u we consider only the actions that 
affect the variables min-seqno(h’), maz-seqno(h’), and scheduled-rgsts?(h’). 


O rm-leave,: if uz.status = crashed, then rm-leave, does not affect the state of RM-CLIENT,. 
Thus, the induction hypothesis implies that the invariant assertion is satisfied in u. Otherwise, 
if u,.status # crashed, then rm-leavey, reinitializes all the variables of SRM-REC, except the 
variable now. It follows that u.min-seqno(h’) =. and u.scheduled-rqsts?(h') = 9. Thus, the 
invariant assertion is satisfied in wu. 


© rm-send,(p), for p © Pra-cueyr, such that source(p) = h’: letting (sp, ip) = id(p), we analyze 
the effects of rm-send;,(p) by cases. First, if a(u,.status = member A h = sp), then rm-send;(p) 
does not affect the state of RM-CLIENT;,. Thus, the induction hypothesis implies that the 
invariant assertion is satisfied in u. 


Second, consider the case where u,.status = member \h = s8,. If ug.min-segno(h’) =L, 
then rm-send;(p) sets min-seqno(h’) and maz-seqno(h’) to ip. Since uz.min-seqno(h’) =L, 
it follows that uz.window?(h') = 9. Thus, the induction hypothesis implies that 


ux. scheduled-rgqsts?(h’) = @. Since rm-send,;(p) does not affect the variable scheduled-rgsts, it 
follows that u.scheduled-rgqsts? (h’) = 0. Thus, the invariant assertion holds in uw. 


Otherwise, if uz.min-seqno(h’) #1, then rm-send;,(p) may only increase the value of the vari- 
able maz-seqno(h’) and does not affect the variable scheduled-rgsts; that is, uzp.window? (h’) C 
u.window?(h’) and u.scheduled-rgqsts(h’) = uz.scheduled-rqsts(h’). Thus, the induction hypothe- 
sis implies that the invariant assertion holds in wu. 


O rep-seqno,(s,i), for s € H, s # h andi € N, such that s = h’: first, if a(ug.status = 

member /\ uz,.min-segno(s) AL Aug.maz-seqno(s) < i), then rep-seqnon(s,7) does not affect the 
state of SRM-REc,. Thus, the induction hypothesis implies that the invariant assertion holds 
in u. 
Otherwise, if u,.status = member, uz.min-seqno(s) AL, and uz.maz-seqno(s) < i, then the ac- 
tion rep-seqno;(s,7) sets maz-seqno(h’) toi. Since uz.maz-seqno(h’) < i and u.maz-seqno(h’) = 
i, it follows that uz.maz-seqno(h’) < u.maz-seqno(h’). The induction hypothesis and the fact 
that uz.maz-seqno(h') < u.max-seqno(h’) imply that the invariant assertion holds in u. 


O schdl-rqstp(s,i), for s € H andi € N, such that s = h’: schdl-rqstp(s,i) adds the 
tuple (s,i) to scheduled-rqsts?(h'). From the precondition of schdl-rqstp(s,7), it follows 
that (s,7) € upz.to-be-requested(h’). Thus, Invariant 5.10 implies that (s,i) € uz.window?(h’). 
Since schdl-rqst;,(s,7) does not affect the variables min-seqno(h’) and maz-seqno(h’), it 
follows that u.window?(h') = uz.window?(h’). From the induction hypothesis, it is the case 
that uz,.scheduled-rqsts?(h’) C up.window?(h'). Since u.window?(h’) = uz.window?(h’) and 


u.scheduled-rgqsts?(h') = upz.scheduled-rqsts?(h’) U (s,i), it follows that the invariant assertion 
hold in wu. 


O send-rqst;,(s,7), for s € H andi €N, such that s = h’: from the precondition of the action 
send-rqst;(s,i), it is the case that (s,7) € ux.scheduled-rqsts?(h'). Since send-rgst;/(s, 7) 
simply backs-off the request scheduled for (s,7), it does not affect min-seqno(h’), max-seqno(h’), 
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and scheduled-rqsts?(h’). Thus, the induction hypothesis implies that the invariant assertion 
holds in wu. 


process-mpkt;(p), for p € Pgrm, such that type(p) = DATA and source(p) = h’: letting 
(Sp,tp) = id(p), we analyze the effects of the process-mpkt;,(p) action by cases. First, if 
uz. status # member, then process-mpkt,,(p) does not affect the state of SRM-REC,. Thus, the 
induction hypothesis implies that the invariant assertion is satisfied in u. 


Second, consider the case where u,z.status = member. If p is neither the foremost nor a 
proper packet from s,, then process-mpkt,,(p) affects neither of the variables min-seqno(h’), 
maa-seqno(h'), and scheduled-rgsts?(h'). Thus, the induction hypothesis implies that the 
invariant assertion holds in wu. 


If p is the foremost packet from s,, then process-mpkt;,(p) sets the variables min-seqno(h’) and 
max-seqno(h') to ip. From the induction hypothesis, it follows that u,.scheduled-rgsts?(h’) = 0. 
Since process-mpkt;,(p) may only remove elements from scheduled-rqsts?(h'), it follows that 
u.scheduled-rgsts?(h') = 0. Thus, the invariant assertion holds in u. 


Finally, if uz.min-seqno(s,) AL, then process-mpkt;,(p) may only remove elements from the 
set scheduled-rqsts?(h’) and increase the value of maz-seqno(h'). Thus, the induction hypothesis 
implies that the invariant assertion holds in wu. 


process-mpkt,(p), for p € Pgrm, such that type(p) = REPL and source(p) = h’: letting 
(Sp,tp) = id(p), we analyze the effects of the process-mpkt;,(p) action by cases. First, if 
uz. status # member, then process-mpkt,,(p) does not affect the state of SRM-REC,. Thus, the 
induction hypothesis implies that the invariant assertion is satisfied in wu. 


Second, consider the case where u,z.status = member. If p is not a proper packet, then the action 
process-mpktp,(p) does not affect the state of SRM-RECc,. Thus, the induction hypothesis 
implies that the invariant assertion holds in u. 


If p is a proper packet, then process-mpkt,;(p) may only remove elements from the variable 
scheduled-rqsts?(h') and increase the value of maz-seqno(h’). Thus, the induction hypothesis 
implies that the invariant assertion holds in u. 


process-mpkt;(p), for p € Psrm, such that type(p) = RQST and source(p) = h’: letting 
(Sp,tp) = id(p), we analyze the effects of the process-mpkt;,(p) action by cases. First, if 
uz. status # member, then process-mpkt,;,(p) does not affect the state of SRM-RECp;. Thus, the 
induction hypothesis implies that the invariant assertion is satisfied in u. 


Second, consider the case where uz.status = member. If p does not pertain to a proper packet, 
then the action process-mpkt,(p) does not affect the state of SRM-REc,. Thus, in this case, 
the induction hypothesis implies that the invariant assertion holds in u. 


If p pertains to a proper packet and h is not the source of p, then process-mpkt;,(p) may add the 
tuple id(p) to scheduled-rqsts?(h') and ensures that ip < u.maz-seqno(h’). Thus, the induction 
hypothesis implies that the invariant assertion holds in wu. 


Invariant 5.12 For h,h’ € H and any reachable state u of SRM-REC,;, it is the case that 
u.to-be-requested(h’) N u.archived-pkts?(h') = Q. 


Proof: Let a be any finite timed execution of SRM-REC, leading to u. The proof is by induction 
on the length n € N of a. For the base case, consider the finite timed execution a of length 0; 
that is, a =u. Since u is a start state of SRM-RECpj, it follows that u.to-be-requested(h’) = 0 and 
u.archived-pkts?(h') = 0. Thus, the invariant assertion is satisfied in u. For the inductive step, 
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consider a timed execution a of length k +1, for k € N. Let a, be the prefix of a@ containing the 
first k steps of a and uz = ax.lstate. For the step from uz to u we consider only the actions that 
affect the variables to-be-requested(h’) and archived-pkts?(h’). 


O rm-leavey,: if uz.status = crashed, then rm-leave, does not affect the state of RM-CLIENT,. 
Thus, the induction hypothesis implies that the invariant assertion is satisfied in u. Otherwise, 
if uz.status # crashed, then rm-leavey reinitializes all the variables of SRM-RECa, except the 
variable now. It follows that u.to-be-requested(h') = @ and u.archived-pkts?(h') = 0. Thus, the 
invariant assertion holds in uw. 


0 rm-send,(p), for p € Pro-cunnr, such that source(p) = h’: letting (sp,ip) = id(p), we analyze 
the effects of rm-sendp(p) by cases. First, if =(u,.status = member A h = sy), then rm-send),(p) 
does not affect the state of RM-CLIENT;. Thus, the induction hypothesis implies that the 
invariant assertion is satisfied in u. 


Second, consider the case where uxz.status = member Ah = sp. If p is the foremost packet to be 
transmitted by h’, that is, uz.min-seqno(h’) =, then it follows that u,.window? (h’) = 0. Thus, 
Invariants 5.4 and 5.10 imply that u,.archived-pkts?(h’) = 0 and ux.to-be-requested(h') = 0). 
If p is the next packet from h’, that is, up.min-seqno(h’) AL and i, = ug.maz-seqno(h’) +1, 
then it is the case that id(p) ¢ ux.window?(h’). Thus, Invariants 5.4 and 5.10 imply that 
id(p) ¢ uz.archived-pkts?(h') and id(p) ¢ uz.to-be-requested(h’). 
In either case the rm-send;,(p) adds id(p) to the variable archived-pkts?(h') and does not 
affect to-be-requested(h’). It follows that u.to-be-requested(h’) = ug.to-be-requested(h') and 
u.archived-pkts?(h’) = uz.archived-pkts?(h’) U id(p). From the induction hypothesis, it is 
the case that ux.to-be-requested(h’) O uz.archived-pkts?(h’) = @. Since it is the case that 
id(p) ¢ ux.to-be-requested(h’), it follows that u.to-be-requested(h’) Q u.archived-pkts?(h') = 0. 
Oj rep-seqnop(s,i), for s € H,s # h andi € N, such that s = A’: first, if a(ug.status = 
member /\ uz.min-seqno(s) AL Auz.maz-seqno(s) < 7), then rep-seqno;(s,7) does not affect 
the state of SRM-RECp,. Thus, the induction hypothesis implies that the invariant assertion 
holds in wu. 


Otherwise, if uz.status = member, uz.min-seqno(s) AL, and uz.maz-seqno(s) < i, then the ac- 
tion rep-seqno,(s,i) adds {(s,7’) | 7’ © N, up.maz-seqno(s) < i! < i} to to-be-requested(h') and 
does not affect archived-pkts?(h’). From Invariant 5.4, it is the case that uz.archived-pkts?(h') C 
uz. window? (h’). Thus, it follows that uz.archived-pkts?(h') {(s,7’) | i’ € N, up.maz-seqno(s) < 
i’ < i} = @. From the induction hypothesis, it is the case that uxz.to-be-requested(h’) M 
Uz. archived-pkts?(h') = 0. Thus, it follows that u.to-be-requested(h') N u.archived-pkts? (h') = 0, 
as needed. 


O schdl-rqstp(s,7), for s € H,i € N, such that s =h’: the schdl-rqstp(s,7) action removes the 
element (s,7) from to-be-requested(h’) and does not affect archived-pkts? (h'). From the induction 
hypothesis, it is the case that uz.to-be-requested(h') N u.archived-pkts?(h') = 0. Thus, it follows 
that u.to-be-requested(h') Q u.archived-pkts? (h') = 0, as needed. 


OC process-mpkt,(p), for p € Psrm, such that type(p) € {DATA,REPL,RQST}, (s,,ip) = id(p), 
and s, = h’: the action process-mpkt;,(p) adds {(s,,i’) | « € N,ug.maz-segno(sp) < 
i’ < i} to to-be-requested(h’) only if h # sp, and upz.max-seqno(s,) < i. Moreover, the 
action process-mpkt;,(p) removes (8,,i,) from to-be-requested(h’) whenever it adds it to 
archived-pkts?(h’). 
Invariant 5.4 implies that u,.archived-pkts? N {(Sp,7’) | i’ € N, ug.maz-seqno(sp) < i! < i} = 0. 
From the induction hypothesis, it is the case that u,.to-be-requested(h’) Nu.archived-pkts? (h’) = 
(). Thus, it follows that the invariant assertion holds in wu. 
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Invariant 5.13 For h,h’ € H and any reachable state u of SRM-REC;, it is the case that 
u.scheduled-rqsts?(h') Q u.archived-pkts?(h') = 0. 


Proof: Let a be any finite timed execution of SRM-REcy,, leading to u. The proof is by induction 
on the length n € N of a. For the base case, consider the finite timed execution a of length 0; 
that is, a = u. Since u is a start state of SRM-RECp, it follows that u.scheduled-rgsts?(h') = 0 
and u.archived-pkts?(h’) = @. Thus, the invariant assertion is satisfied in u. For the inductive step, 
consider a timed execution a of length k+ 1, for k € N. Let ax be the prefix of a@ containing the 
first & steps of a and uz = ay. lstate. For the step from uz to u we consider only the actions that 
affect the variables scheduled-rqsts?(h’) and archived-pkts?(h’). 


O rm-leave,: if uz.status = crashed, then rm-leave, does not affect the state of RM-CLIENTy,. 
Thus, the induction hypothesis implies that the invariant assertion is satisfied in u. Otherwise, 
if u,.status # crashed, then rm-leavey, reinitializes all the variables of SRM-REC, except the 
variable now. It follows that u.scheduled-rgqsts?(h') = 0 and u.archived-pkts?(h’) = 0. Thus, the 
invariant assertion holds in wu. 


© rm-send,(p), for p © Pra-cueyr, such that source(p) = h’: letting (sp, ip) = id(p), we analyze 
the effects of rm-send;,(p) by cases. First, if a(u,.status = member A h = sp), then rm-send;(p) 
does not affect the state of RM-CLIENT,. Thus, the induction hypothesis implies that the 
invariant assertion is satisfied in wu. 


Second, consider the case where uxz.status = member \ h = sp. If p is the foremost packet to be 
transmitted by h’, that is, uz.min-seqno(h’) =1, then it follows that u,.window? (h’) = 0. Thus, 
Invariants 5.4 and 5.11 imply that ux.scheduled-rqsts?(h’) = @ and ux.archived-pkts?(h') = 0. 
If p is the next packet from h’, that is, up.min-seqno(sp) AL and ip = up.max-seqno(sp) + 1, 
then it is the case that id(p) ¢ ux.window?(h’). Thus, Invariants 5.4 and 5.11 imply that 
id(p) ¢ uz.scheduled-rqsts?(h’) and id(p) ¢ up.archived-pkts?(h’). 


In either case the rm-send;(p) adds id(p) to the variable archived-pkts?(h’') and does not 
affect scheduled-rgsts?(h’). It follows that u.scheduled-rgsts?(h’) = uz.scheduled-rgsts?(h’) and 
u.archived-pkts?(h’) = up.archived-pkts?(h’) U id(p). From the induction hypothesis, it is 
the case that uxz.scheduled-rqsts?(h’) 1 ux.archived-pkts?(h’) = @. Since it is the case that 
id(p) ¢ ux.scheduled-rqsts?(h'), it follows that u.scheduled-rqsts? (h') N u.archived-pkts?(h’) = 0, 
as needed. 


O schdl-rqst;(s,i), for s € H,i € N, such that s = h’: the schdl-rqst,;,(s,7) action schedules 
a request for (s,i) and does not affect archived-pkts?(h'); that is, u.scheduled-rgsts?(h') = 
uz. scheduled-rgqsts?(h’) U (s,i) and u.archived-pkts? (h') = uz.archived-pkts? (h’). 


From the precondition of schdl-rqsta(s,7), it follows that (s,i) € wup,.to-be-requested(h’). 
From Invariant 5.12, it follows that (s,7) ¢ up.archived-pkts?(h’). Since it is the case that 
u.archived-pkts? = uz.archived-pkts?, it follows that (s,i) ¢ u.archived-pkts?(h’'). From the 
induction hypothesis, it is the case that u,.scheduled-rqsts?(h’) N ugz.archived-pkts?(h') = 0. 
Thus, it follows that u.scheduled-rgsts?(h') Q u.archived-pkts?(h') = Q, as needed. 

O send-rqst),(s,7), for s € H,i € N, such that s = h’: from the precondition of send-rgst;(s, 7), 
it is the case that (s,i) € u,.scheduled-rqsts?(h'). Since send-rqst;(s,i) simply backs-off 
the request scheduled for (s,7), it follows that u.scheduled-rqsts?(h’) = up.scheduled-rqsts?(h’). 
Moreover, send-rqstp(s,7) does not affect the variable archived-pkts?(h’). Thus, it follows that 
u.archived-pkts?(h') = up.archived-pkts?(h’). Thus, the induction hypothesis implies that the 
invariant assertion holds in uw. 

O process-mpktp(p), for p € Psam, such that type(p) € {DATA,REPL} and source(p) = h’: in 
this case, if the process-mpkt,(p) action archives the packet strip(p), then it also cancels any 
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requests scheduled for id(p). Thus, the induction hypothesis implies that the invariant assertion 
holds in wu. 


© process-mpktp(p), for p € Psrm, such that type(p) = RQST and source(p) = h’: in this 
case, the process-mpkt;,(p) action schedules a request for id(p) only if h # s, and id(p) ¢ 
uz. archived-pkts?(h'). Thus, the induction hypothesis implies that the invariant assertion holds 
in u. 


Invariant 5.14 Let u be any reachable state of SRM-REC,. For s € H, i €N, t,t’ © R=°, and 
keEN™, if (s,i,t) © pending-rgqsts and (s,i,t',k) € scheduled-rgsts, then t < t’. 


Proof: From Assumption 5.1, it is the case that C3 < C;. Thus, the expiration time of the 
back-off abstinence period precedes the transmission time of the respective request. a 


Invariant 5.15 Let u be any reachable state of SRM-RECy,. For h,s € H andi € N, if 
the action send-rqstp(s,i) is enabled in u, i.e., u.Pre(send-rqst;,(s,i)) = True, then (s,i) ¢ 
u.pending-rqsts? . 


Proof: Suppose that u.Pre(send-rqst;,(s,i)) = True. From the precondition of the action 
send-rqst,,(s,i), it follows that there exists k € Nt such that (s,7,t’,k) € scheduled-rgsts, for t! = 
u.now. Invariant 5.14 implies that there does not exist t € R=° such that (s,i,t) € pending-rqsts 
and t’ < t. Since t/ = u.now, it follows that (s,7) ¢ u.pending-rgqsts?. 


We proceed by presenting several lemmas pertaining to the RM; automaton. 


Lemma 5.2 Let p © Pru-curnt, a be any finite timed execution fragment of RM;, and u,u’ € 
states(RM_), such that u=a.fstate and u' = a.lstate. If p € u[SRM].sent-pkts, then it is the case 
that p € u'[SRM].sent-pkts. 


Proof: Follows directly from the fact that the variable trans-time(p) may only be set by the 
automaton RM; to a value other than L. In particular, the variable trans-time(p) may only be set 
by the action rm-sendp(p), for h = source(p), to the value of the variable now of the automaton 
SRM-RECy,. |_| 


Lemma 5.3 Let s,h © H,i€ N, andu€ states(RM,) be any reachable state of RM, such that 
(s,27) € u[SRM-RECp].archived-pkts?. Moreover, let a be any timed execution fragment of RM, 
that starts in u, does not contain a rm-leavep action, and ends in some u’ € states(RM,). Then, 
it is the case that (s,1) € u'[SRM-REC)].archived-pkts? . 


Proof: Follows from a simple induction on the length of a. The key point of the induction is 
that none of the actions of SRM-RECa, except the action rm-leave, which is not contained in a, 
remove elements from or initialize the set SRM-REC,.archived-pkts? . |_| 


Lemma 5.4 Let s,h © H,ie€ N, andu€ states(RM,) be any reachable state of RM, such that 
(s,7) € u[SRM-REC,].scheduled-rqsts?. Moreover, let a be any timed execution fragment of RM_ 
that starts in u, does not contain a rm-leavep action, and ends in some u’ € states(RM,). Then, 
either (s,i) € w’[SRM-RECa].scheduled-rgqsts? or (s,i) € u'[SRM-RECp].archived-pkts? . 
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Proof: Follows from a simple induction on the length of a. The key points of the induction 
are that: i) whenever the elements of SRM-REC).scheduled-rgqsts pertaining to (s,7) are removed 
from SRM-RECy.scheduled-rqsts then either another element pertaining to (s,7) is added to 
SRM-REC),.scheduled-rqsts or (s,1) € SRM-RECp.archived-pkts?, and ii) from Lemma 5.3, none 
of the actions of SRM-RECp, except the action rm-leave;, which is not contained in a, remove 
elements from the set SRM-RECa.archived-pkts?. | 


Lemma 5.5 Let s,h ¢ H,icN, te R@°, k © N*, andu€ states(RM;) be any reachable state of 
RM,, such that u|[SRM-RECp].status = member and (s,i,t,k) € u[SRM-REC,].scheduled-rgsts. 
Moreover, let a be any timed execution fragment of RM, that starts in u, contains neither 
crash, nor rm-leave,, actions, and ends in some u’ © states(RMy), such that t < u’.now and 
(s,i,t’,k’) € u'[SRM-RECp].scheduled-rgsts, for t' € R=° and k' © Nt. Then, it is the case that 
bak 


Proof: Invariant 5.13 and Lemma 5.4 imply that in any state wu” in a it is the case that 
(s,7) € u"[SRM-RECp].scheduled-rqsts?. However, since (s,7,t,k) € u[SRM-RECp].scheduled-rqsts, 
t < u’.now and time is not allowed to progress past the scheduled transmission time of any request, 
it follows that the request for (s,i) is rescheduled for transmission in a for a point in time no 
earlier than u’.now. The only actions that may reschedule the request for (s,7) are the actions 
send-rqstp(s,i) and process-mpktp(p), for _p € Pgrm, such that id(p) = (s,i) and type(p) = RQST. 
Whenever either of these actions reschedule the request for (s,7), they increment the element of 
the tuple corresponding to the round count. | 


Lemma 5.6 The occurrence of an action send-rqstp(s,i), for h,s € H, andi € N, in any 
admissible timed execution a of RMy is instantaneously succeeded in a by the occurrence of either 
a crashp,, rm-leave,, or rec-msend,(p) action, where p € Pgpm is a retransmission request for 
the packet (s,i). 


Proof: The send-rqst,(s,7) action adds a RQST packet for (s,i) to the variable 
SRM-REC),.msend-buff . Moreover, SRM-RECp prevents time from elapsing while it is 
the case that SRM-RECp.status 4 crashed \ SRM-REC),.msend-buff 4 0. | 


Lemma 5.7 The occurrence of an action send-replp(s,i), for h,s € H andi € N, in any 
admissible timed execution a of RMy is instantaneously succeeded in a by the occurrence of either 
acrashp,, rm-leaven, or rec-msend;,(p) action, where p € Psrm is a retransmission of (reply for) 
the packet (s,1). 


Proof: The send-repl,(s,7) action adds a REPL packet for (s,i) to the variable 
SRM-REC),.msend-buff . Moreover, SRM-REC, prevents time from elapsing while it is 
the case that SRM-RECp.status 4 crashed \ SRM-RECa.msend-buff 4 0. | 


Lemma 5.8 The occurrence of an action rec-msend;(p), for h € H and p € Pgrm, in any 
admissible timed execution a of RMy is instantaneously succeeded in a by the occurrence of either 
a crash, rm-leave;,, or msend;(pkt) action, for pkt © Prpycasr-Cumnr, Such that strip(pkt) = p. 


Proof: The rec-msend;(p) action adds an element to the variable SRM-IPBUFF;,.msend-buff. 


Moreover, SRM-IPBUFF,, prevents time from elapsing while SRM-IPBUFF,).status # crashed A 
SRM-IPBUFF),.msend-buff 4 0. | 


57 


Lemma 5.9 The occurrence of an action mrecv;(pkt), for h € H and pkt € Pgpm, in a state 
u € states(RMz,) in any admissible timed execution a of RMz, such that u[SRM-MEM)].status = 
member, is instantaneously succeeded in a by the occurrence of either a crash), rm-leave,, or 
process-mpktp(p) action, for p € Pspm, such that p = strip(pkt). 


Proof: Since u[SRM-MEM)].status = member, the particular occurrence of the mrecvy,(pkt) 
action adds an element pertaining to pkt to the variable SRM-IPBUFF,.mrecu-buff. More- 
over, SRM-IPBUFF, prevents time from elapsing while SRM-IPBUFFy).status #~ crashed A 
SRM-IPBUFF,.mrecv-buff 4 0. a 


Lemma 5.10 Let a be any admissible execution of RM, containing the discrete transition 
(u,7,u’), for u,u’ € states(RMr), h © H, p © Prm-cumyr, (Sp,tp) = td(p), and 7 = rm-send,(p). 
If it is the case that either u[SRM-RECp].min-seqno(sp) =L or u[SRM-RECp].min-seqno(sp) AL 
Nip = u[SRM-RECp].maz-seqno(s,) + 1, then the discrete transition (u,m,u’) is instantaneously 
succeeded in a by the occurrence of either a crashy,, rm-leaven, or rec-msend;(p’) action, for 
p' = comp-data-pkt(p). 


Proof: Suppose that either u[SRM-REC;].min-seqno(sp) =L or u[SRM-RECp].min-seqno(sp) AL 
and ip = u{[SRM-REC;].maz-seqno(s,) + 1. Then, the discrete transition (u,7,u’) adds the 
element p’ to SRM-RECp.msend-buff. Moreover, SRM-REC;, prevents time from elapsing while 
SRM-REC),.status #4 crashed \ SRM-REC).msend-buff # 0. fe 


We now present some invariants pertaining to the RM; automaton. 


Invariant 5.16 For h € H and any reachable state u of RMz, it is the case that: 


1. u[RM-CLIENT;].status = idle = u[SRM-MEMa].status = idle, 

2. u[RM-CLIENT)].status = member © u[SRM-MEM)].status = member, 

3. u[ RM-CLIENT),].status = crashed = u[SRM-MEMp].status = crashed, 

4. u[RM-CLIENT,,].status = joining = u[SRM-MEMa].status € Joining, and 
5. u[RM-CLIENT)|].status = leaving = u[SRM-MEM)].status € Leaving. 


Proof: Let a be any finite timed execution of RM, leading to u. The proof is by induction on 
the length n € N of a. For the base case, consider the finite timed execution a of length 0; that 
is, a =u. Since u is a start state of RM, it is the case that u[RM-CLIENT;].status = idle and 
u[SRM-MEM)].status = idle. Thus, the invariant assertion is satisfied in u. For the inductive 
step, consider a timed execution a of length k +1, for k € N. Let a, be the prefix of a containing 
the first k steps of a and uz = ag.lstate. For the step from uz to u we consider only the actions 
that affect the variables RM-CLIENT),.status and SRM-MEM)p.status. 


O crash;,: the action crash; sets both variables RM-CLIENT,.status and SRM-MEMp).status to 
the value crashed. Thus, the invariant assertion holds in uw. 


O rm-joinp: from the precondition of the xrm-join, action, it follows that 
uz{|RM-CLIENT)].status = idle. From the induction hypothesis it follows that 
uz|SRM-MEM),|.status = idle. Thus, the action rm-join, sets RM-CLIENT),,.status to joining 
and SRM-MEMp.status to join-rqst-pending; that is, u[RM-CLIENT,].status = joining and 
u[SRM-MEM)].status € Joining. It follows that the invariant assertion holds in w. 
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OG mjoin,: from the precondition of the mjoin;, action, it follows that uz{[SRM-MEM)].status € 
Joining. From the induction hypothesis it follows that u,{RM-CLIENT;].status = joining. 
The action mjoin, sets the variable SRM-MEMpg.status to join-pending and does not affect 
the variable RM-CLIENT,. status. Thus, it is the case that u[SRM-MEM,].status € Joining and 
u|RM-CLIENT;,].status = joining. It follows that the invariant assertion holds in uw. 


OC mjoin-ack;,: we first consider the case where ux[SRM-MEMa].status ¢ Joining. In this case, 
mjoin-ack, affects neither RM-CLIENT),.status nor SRM-MEMa.status. Thus, the induction 
hypothesis implies the invariant assertion in wu. 


Second, we consider the case where uz{SRM-MEMp].status € Joining. In this case, 
mjoin-ack, sets the variable SRM-MEMpg,.status to join-ack-pending and does not affect 
RM-CLIENTy.status. Since uz[SRM-MEMp].status € Joining, the induction hypothesis 
implies that uz,[RM-CLIENT)].status = joining. Moreover, since mjoin-ack, does not affect 
RM-CLIENT). status, it follows that u{RM-CLIENT;].status = joining. Thus, the invariant 
assertion holds in wu. 


Oj rm-join-ack,: from the precondition of rm-join-ackp, it follows that uz{SRM-MEMa].status € 
Joining. From the induction hypothesis it follows that uz{[RM-CLIENT,;].status = joining. 
Thus, the rm-join-ack, action sets both SRM-MEMa.status and RM-CLIENT,.status to 
member. It follows that the invariant assertion holds in uw. 


rm-leave,: the reasoning for this action is analogous to that of rm-joing. 
mleave,: the reasoning for this action is analogous to that of mjoinp. 


mleave-acky: the reasoning for this action is analogous to that of mjoin-ack,. 


Od 0 0 


rm-leave-ack,: the reasoning for this action is analogous to that of rm-join-ackp. 


Invariant 5.17 For h € H and any reachable state u of RMy,, it is the case that 
u[RM-CLIENTp;].seqno = u[SRM-REC;].maz-seqno(h). 


Proof: Let a@ be any finite timed execution of RM; leading to u. The proof is by induction 
on the length n € N of a. For the base case, consider the finite timed execution a of length 
0; that is, a = u. Since wu is a start state of RM,, it follows that u[RM-CLIENT,;].segno =L 
and u[SRM-RECa].maz-seqno(h) =1L. Thus, the invariant assertion is satisfied in u. For the 
inductive step, consider a timed execution a of length k +1, for k € N. Let ax be the prefix of a 
containing the first k steps of a and uz = ag.listate. For the step from uz, to u, we consider only 
the rm-send;,(p) action, since this is the only action that affects the variables RM-CLIENT,;.seqno 
and SRM-REC;,.maz-seqno(h). 


From the precondition of rm-sendaj(p), it is the case that ux/RM-CLIENT,].status = member, 
source(p) = h, and either uz,{[RM-CLIENT)].segno = or segno(p) = ux[|RM-CLIENT),].seqno + 1. 
The effects of rm-send,;(p) are to set RM-CLIENT),.seqgno to seqno(p). 


Since ux[RM-CLIENT;)].status = member, Invariant 5.16 implies that it is the case that 
uz|SRM-REC,,].status = member. From the induction hypothesis, it is the case that 
up{|RM-CLIENT;)].seqno = ux[SRM-REC,].maz-seqno(h). Thus, it is the case that either 


uz{SRM-REC,,].maz-seqno(h) =L or seqno(p) = uz[SRM-REC,].maz-seqno(h) + 1. In either 
case, the rm-send,(p) sets SRM-RECp.maz-seqno(h) to segno(p). Thus, it follows that 
u[RM-CLIENTp].seqno = u[SRM-REC;].maz-seqno(h). a 


Invariant 5.18 For h € H and any reachable state u of RMyz, it is the case that: 
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1. u[SRM-MEMp].status = crashed © u[SRM-IPBuFF;].status = crashed 
Au[SRM-MEMp|.status = member = u[SRM-IPBUFFp].status = member, 

2. u[SRM-MEm)].status = crashed © u[SRM-RECp].status = crashed 
Au|SRM-MEMa].status = member = u[SRM-REc,,].status = member, and 

3. u[SRM-MEmM)].status = crashed © u[SRM-REP;,].status = crashed 
Au[SRM-MEMp].status = member © u[SRM-REP»].status = member. 


Proof: We prove that u[SRM-MEMp].status = crashed = u[SRM-IPBUFF,].status = crashed A 
u|[SRM-MEM,,].status = member © u[SRM-IPBUuFF,,].status = member; the proofs of the remaining 
claims are analogous. 


Let a@ be any finite timed execution of RM, leading to u. The proof is by induction on the 
length n € N of a. For the base case, consider the finite timed execution a@ of length 0; that 


is, 


a =u. Since u is a start state of RM, it follows that u[SRM-MEM)].status = idle and 


u{[SRM-IPBUFF)].status = idle. Thus, the invariant assertion is satisfied in u. For the inductive 
step, consider a timed execution a of length k +1, for k €¢ N. Let a, be the prefix of @ containing 
the first k steps of a and uz = ag.lstate. For the step from ux to u, we consider only the actions 
that affect the variables SRM-MEMp.status and SRM-IPBUFFy). status. 


0 


0 


Oo 


Oo 


crashp: the action crashp, sets both variables SRM-MEMy).status and SRM-IPBUFFy». status to 
the value crashed. Thus, the invariant assertion holds in uw. 


rm-join,: from the precondition of rm-join,, it follows that uz,[RM-CLIENT);].status = 
idle. Invariant 5.16 implies that u,[/[SRM-MEmM,].status = idle. Since 
up|SRM-MEM)].status ¢ {crashed,member}, the induction hypothesis implies that 
uz[SRM-IPBUFFp].status ¢ {crashed, member}. 


Since xrm-join, sets SRM-MEMp.status to join-rqst-pending, it follows that 
u[SRM-MEM)].status ¢ {crashed,member}. Since rm-join, does not affect the vari- 
able SRM-IPBUFFy),.status, it follows that u[SRM-IPBuFF,].status ¢ {crashed, member}. 
Thus, it follows that the invariant assertion holds in u. 


mjoin,: from the precondition of mjoiny, it follows that uz{[SRM-MEM)].status € Joining; that 
is, upx[{SRM-MEMa].status ¢ {crashed,member}. Thus, the induction hypothesis implies that 
ux[SRM-IPBUFFp].status ¢ {crashed, member}. 


Since the action mjoin,, sets the variable SRM-MEMy),.status to join-pending, it follows that 
u[SRM-MEMy,].status ¢ {crashed,member}. Moreover, since mjoin, does not affect the variable 
SRM-IPBuFFy,. status, it follows that u[SRM-IPBUFF)].status ¢ {crashed,member}. Thus, it 
follows that the invariant assertion holds in wu. 


mjoin-ackp: first, consider the case where ux[SRM-MEMp].status ¢ Joining. Since in this 
case mjoin-acky,, affects neither SRM-MEM,,.status nor SRM-IPBUFFp.status, the induction 
hypothesis implies that the invariant assertion holds in w. 


Second, consider the case where uxg[/SRM-MEMa|].status € Joining. Since 
uz|SRM-MEM),]|.status ¢ {crashed,member}, the induction hypothesis implies that 
ux[SRM-IPBUFFp].status ¢ {crashed,member}. Since uz[SRM-MEM)].status € Joining, 
the action mjoin-ack, sets SRM-MEMp.status to join-ack-pending; that is, 
u[SRM-MEM)].status ¢ {crashed,member}. Since mjoin;, does not affect the variable 
SRM-IPBuFF,. status, it follows that u[SRM-IPBUFF,].status ¢ {crashed,member}. Thus, it 
follows that the invariant assertion holds in wu. 


rm-join-ack;: from the precondition of srm-join-ack,, it is the case that 
ug[SRM-MEMp|].status € Joining. Since ux[SRM-MEMp|].status ¢ {crashed,member}, 
the induction hypothesis implies that uz,[SRM-IPBUFFp].status ¢ {crashed, member}. 
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The action rm-join-ack,, sets SRM-MEMy,.status to member. Since uz[SRM-IPBUFFa].status 4 
crashed, it also sets SRM-IPBUFFy.status to member. It follows that the invariant assertion 
holds in wu. 


O rm-leave;: from the precondition of the action srm-leave,, it follows 
that ux[RM-CLIENT;,].status = member. Thus, Invariant 5.16 implies that 
uz{|SRM-MEM),]|.status = member. Moreover, the induction hypothesis implies that 


up| SRM-IPBUFF,].status = member. 


Since uz([SRM-MEM)].status = member, the rm-leave, action sets SRM-MEMp).status 
to leave-rqst-pending and SRM-IPBUFF).status to idle. Thus, it is the case that 
u|[SRM-MEM,,].status ¢ {crashed,member} and u[SRM-IPBUFF»)].status ¢ {crashed, member}. 
Thus, it follows that the invariant assertion holds in wu. 

O mleave,: the reasoning for this action is analogous to that of mjoiny. 


O mleave-acky: the reasoning for this action is analogous to that of mjoin-ackp. 


O rm-leave-ack;: from the precondition of the action rm-leave-ack,, it follows that 
uz|SRM-MEM),|.status =  leave-ack-pending. Since uz([SRM-MEMp].status  ¢ 
{crashed,member}, the induction hypothesis implies that u,/SRM-IPBUFF)].status ¢ 
{crashed, member}. 


The action rm-leave-ack,, sets SRM-MEMp.status to idle and does not affect the variable 
SRM-IPBurFF,.status. Thus, it follows that u[SRM-MEMp].status ¢ {crashed,member} and 
u[SRM-IPBUFFy)].status ¢ {crashed,member}. Thus, it follows that the invariant assertion 
holds in wu. 


Invariant 5.19 For any reachable state u of RM,, it is the case that 
u[SRM-REC)].archived-pkts? C u[SRM].sent-pkts?, for all h € H. 


Proof: Let a be any finite timed execution of RM; leading to u. The proof is by strong induction 
on the length n € N of a. For the base case, consider the finite timed execution a of length 0; that 
is, a= u. Since wu is a start state of RMz, it is the case that u[SRM-RECa].archived-pkts? = 0, for 
all h € H, and u[SRM].sent-pkts? = 0. Thus, the invariant assertion is trivially satisfied in u. For 
the inductive step, consider a timed execution a of length k+1, fork € N. Let a, be the prefix of a 
containing the first k steps of a and uz = a,z.lstate. For the step from u;, to u we consider only the 
actions that affect the variables SRM-RECy.archived-pkts?, for all h € H, and SRM.sent-pkts?. 


O rm-leaven, for h € H: the action rm-leavey, reinitializes the variable SRM-RECy.archived-pkts. 
Thus, since u[SRM-REC;].archived-pkts = @), it follows that u[SRM-RECp].archived-pkts? C 
u[SRM].sent-pkts?. 


Oj rm-send;(p), forh € H and p € Pam-curnr: the action rm-send,(p) adds the element (p, now) to 
the variable SRM-RECpj.archived-pkts if and only if it sets the variable SRM-RECa.trans-time(p) 
to now; that is, it adds the element id(p) to SRM-RECaj.archived-pkts? if and only if it adds it to 
SRM. sent-pkts?. Thus, the induction hypothesis implies that u[SRM-REc),].archived-pkts? C 
u[SRM].sent-pkts?. 


O process-mpkt,,(p), for h € H and p € Pgrm, such that type(p) € {DATA, REPL}: from the pre- 
condition of process-mpkt,,(p), it follows that there exists pkt € uz{[SRM-IPBUFF;].mrecv-buff, 
such that strip(pkt) = p. Since the only action that may add pkt to the variable 
SRM-IPBUFF).mrecv-buff is mrecv;,(pkt), it follows that the action process-mpkt,;(p) is pre- 
ceded in ax by an action mrecvp(pkt). Let (u2,mrecvp(pkt),u1) be the discrete transition in 


61 


Qz corresponding to the particular occurrence of the action mrecv;(pkt). Lemma 5.1 implies 
that the action mrecvp;(pkt) is preceded in az by an action msendp,(pkt), for some h’ € H. Let 
(u4,msend,,(pkt),u3) be the discrete transition in a; corresponding to the particular occurrence 
of the action msend;,(pkt). From the precondition of the action msendy;(pkt), it follows that 
pkt € u4[SRM-IPBUFF,’|.msend-buff . 


Since the only action that may add packets of type DATA or REPL to the variable 
SRM-IPBUFF).msend-buff is the action rec-msend;(p), it follows that an action 
rec-msend,/(p) precedes ua in ax. Let (ug,rec-msend;,(p),us) be the discrete transition 
in a, corresponding to the particular occurrence of the action rec-msendpj/(p). From the 
precondition of the action rec-msend;,(p), it follows that p € ug[SRM-RECp’|.msend-buff. 
Invariant 5.7 implies that id(p) € u¢g{[SRM-RECy,].archived-pkts?. From the induction 
hypothesis it is the case that ug[SRM-RECp].archived-pkts? C ug/SRM].sent-pkts?. Thus, 
Lemma 5.2 implies that id(p) € u[SRM].sent-pkts?. Since the action process-mpktp(p) 
may only add the tuple (strip(p),now) to the variable u[SRM-REC);].archived-pkts, 
the fact that id(p) ©€ u[SRM].sent-pkts? and the induction hypothesis imply that 
u[SRM-REC)].archived-pkts? C u[SRM].sent-pkts?, as needed. 


Invariant 5.20 For h € H and any reachable state u of RMy,, it is the case that 
u[SRM-REC;].to-be-delivered? C u[SRM].sent-pkts?. 


Proof: Invariant 5.3 implies that, for h’ € A, it is the case’ that 
u|[SRM-REC)].to-be-delivered?(h’) C u[SRM-RECc)].archived-pkts?(h'). Thus, it is the case 
that u[SRM-REC;,].to-be-delivered? C u[SRM-REC)].archived-pkts?. Invariant 5.19 implies that 
u[SRM-REC)].to-be-delivered? C u[SRM].sent-pkts?. a 


5.4.3 Relation Definition 


We define a relation, R, from RM; to RMg(A), for any A € R29 U oo. 


Definition 5.1 Let R be the relation between states of RM; and RMsg(A), for any A € R7° Uco, 
such that for any states u and s of RM; and RMs(A), respectively, (u,s) € R provided that, for 
allh,h’ © H and p © Prm-cumnr, such that (Sp, ip) = id(p), it is the case that: 


S.now = u.now 
s[RM-CLIENT,].status = u[RM-CLIENT)].status 
s[RM-CLIENT)].seqno = u[RM-CLIENT)].seqno 
idle if ulSRM-MEM,]|.status = idle 
joining if ul/SRM-MEM)].status € Joining 
s[RM(A)].status(h) = 4 leaving if u[SRM-MEMp].status € Leaving 
member if u[SRM-MEM,].status = member 


crashed if u[SRM-MEMp|.status = crashed 
s[RM(A)].trans-time(p) = u[SRM-RECg,].trans-time (p) 
s[RM(A)].expected(h, h’) = u[SRM-RECp].expected(h’) 
s[RM(A)].delivered(h, h’) = u[SRM-RECp].delivered(h’) 
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5.4.4 Safety Analysis 


In this section, we show that our reliable multicast implementation RM, indeed implements the 
reliable multicast service specification RMs(co). The following lemma states that the relation R 
of Definition 5.1 is a timed forward simulation relation from RM; to RMsg(co). 


Lemma 5.11 R is a timed forward simulation relation from RM; to RMsg(co). 


Proof: We must show that: i) if u € start(RMz,), then there is some s € start(RMg(co)) such 
that (u,s) € R, and ii) if wu is a reachable state of RM, s is a reachable state of RMg(co) such 
that (u,s) € R, and (u,7,u’) € trans(RM7), then there exists a timed execution fragment a of 
RMs(oo) such that: a.fstate = s, ttrace(a) = ttrace(uru’), the total amount of time-passage in a 
is the same as the total amount of time-passage in uu’, and (u’,s’) € R, for s’ = a.lstate. 


The satisfaction of the start condition is straightforward. For the step, we consider only the actions 
in acts(RMz) that affect the variables of RM, that are used in R to obtain the corresponding state 
in RMs(co). Moreover, since the client automata RM-CLIENTa, for all h € H, are identical in 
both RM; and RMsg(oco), we do not consider the effect of the actions of RM; on the state of the 
client automata. Thus, we consider only the actions of the SRM component of RM, that affect 
the variables of SRM that are present in R. 


O crashp, for any h € H: the corresponding execution fragment of RM (co) is comprised solely of 
the crash; action. The crash, action of RM; simply sets the variable u[SRM-MEMp].status to 
crashed and resets u[SRM-RECp].expected(h’) and u[SRM-RECa;].completed(h’), for all h’ € H. 
It is straightforward to see that the crash; action of RMs(oo) mirrors these effects. Thus, it 
follows that (u’, s’) € R. 


O rm-joing, for any h € H: the corresponding execution fragment of RMg(co) is comprised solely 
of the rm-join, action. It is straightforward to see that the effects of the rm-join, action in 
the specification correspond to those in the implementation. 


O mjoin,, for any h € H: the corresponding execution fragment of RMsg(oo) is the empty 
timed execution fragment. Since the mjoin;, action is enabled in state u, it follows that 
u|[SRM-MEM,].status € Joining. Thus, R implies that s[RM(oo)]|.status(h) = joining. The 
effects of the mjoin, action are to set the status variable to join-pending. It follows that 
u'[SRM-MEMa].status € Joining. Since the corresponding execution fragment of RM (co) is the 
empty timed execution fragment it is the case that s’ = s and s'[RM(oo)].status(h) = joining. 
Thus, it follows that (u’,s’) € R. 


O mjoin-ack,, for any h € H: the corresponding execution fragment of RMg(oo) is the 
empty timed execution fragment. The mjoin-ack, action affects the state of the SRM-MEM,, 
automaton only when the host A is in the process of joining the reliable multicast group; that 
is, u[SRM-MEMp].status € Joining. Thus, R implies that s[RM(oo)].status(h) = joining. The 
effects of the mjoin-acky,, action are to set the status variable to join-ack-pending. It follows 
that u'[SRM-MEM,].status € Joining. Since the corresponding execution fragment of RM (oo) 
is the empty timed execution fragment it is the case that s’ = s and s’/[RM(oo)].status(h) = 
joining. Thus, it follows that (u’,s’) € R. 

OG rm-leaven, for any h € H: the corresponding execution fragment of RM s5(0o) is comprised solely 
of the rm-leave, action. From the precondition of the rm-leave, action in the RM-CLIENT;, 
automaton, it follows that u[RM-CLIENT,,].status = member. Thus, Invariant 5.16 implies that 


u[SRM-MEM)].status = member and, since (u,s) € R, it is the case that s[RM(oo)].status(h) = 
member. 
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Since u[SRM-MEMa|].status = member, the rm-leave, action of RM; sets the status variable 
of SRM-MEM,, to leave-rqst-pending. The rm-leavey,, action of RMs(oc) sets the status(h) 
variable of RM(co) to leaving. Thus, it follows that u’/[SRM-MEM,].status € Leaving and 
s'[RM(oo)].status(h) = leaving, as required by R. 


Moreover, the rm-leave;, action of RM, resets the expected and delivered packet sets of 
SRM-REC); that is, u’[SRM-REC)].erpected(h’) = @ and u'[SRM-RECa].delivered(h’) = 0, 
for all h’ € H. Similarly, the rm-leave; action of RMg(oo) also resets the variables 
expected(h,h’) and delivered(h,h'), for h’ € H; that is, s’[RM(co)].expected(h,h’) = @ and 
s'[RM(oo)].delivered(h, h’) = 0. Thus, it follows that (u’, s’) € R. 


mleave,, for any h € H: the corresponding execution fragment of RMg¢5(oo) is the empty 
timed execution fragment. Since the mleave;, action is enabled in state u, it follows that 
u|[SRM-MEM,].status € Leaving. Thus, R implies that s[RM(oo)].status(h) = leaving. 
The effects of the mleave;, action of RM; are to set the status variable of SRM-MEM,, to 
leave-pending. It follows that u’[SRM-MEM,].status € Leaving. Since the corresponding 
execution fragment of RMs5(oo) is the empty timed execution fragment it is the case that s’ = s 
and s'[RM(oco)].status(h) = leaving. Thus, it follows that (u’,s’) € R. 


mleave-ack,, for any h € H: the corresponding execution fragment of RMg(oo) is the 
empty timed execution fragment. The mleave-ack, action affects the state of the SRM-MEMy, 
automaton only when the host h is in the process of leaving the reliable multicast group; that is, 
u|[SRM-MEM,].status € Leaving. In this case, R implies that s[RM(oo)]|.status(h) = leaving. 
The effects of the mleave-ack;, action of RM, are to set the status variable of SRM-MEMy, to 
leave-ack-pending. It follows that u’[SRM-MEM,].status € Leaving. Since the corresponding 
execution fragment of RM¢(co) is the empty timed execution fragment it is the case that s’ = s 
and s'[RM(oco)].status(h) = leaving. Thus, it follows that (u’,s’) € R. 


rm-join-ack;, for any h € H: the corresponding execution fragment of RM (oo) is comprised 
solely of the rm-join-ack,, action. We begin by showing that the rm-join-ack, action of 
RMs(oo) is enabled in s. The precondition of the rm-join-ack,, action of RM; implies that 
u[SRM-MEM,].status € Joining. Since (u,s) € R, it follows that s[RM(oo)].status(h) = 
joining. Thus, it follows that the rm-join-ack,y, action of RMg(oo) is enabled in s. 


The rm-join-ack,, action of RM; sets the status variable of SRM-MEM, to member. Similarly, 
the rm-join-ack, action of RM (oc) sets the status(h) variable of RMg(co) to member. Thus, 
it follows that (u’,s’) € R. 


rm-leave-acka, for any h € H: the corresponding execution fragment of RM (oo) is comprised 
solely of the rm-leave-acky, action. We begin by showing that the rm-leave-ack, action 
of RMsg(oo) is enabled in s. The precondition of the rm-leave-ack, action of RM; implies 
that u[SRM-MEMap].status € Leaving. Since (u,s) € R, it follows that s[RM(oo)].status(h) = 
leaving. Thus, it follows that the rm-leave-ack,, action of RM (oo) is enabled in s. 


The rm-leave-ack,, action of RM, sets the status variable of SRM-MEM, to idle. Similarly, 
the rm-leave-ack, action of RMg(oo) sets the status(h) variable of RMg(co) to idle. Thus, 
it follows that (u’,s’) € R. 


rm-send,(p), for any h € H and p € Pry-ciumnt: the corresponding execution fragment of 
RMs(co) is comprised solely of the rm-send,(p) action. Let s, and i, denote the source and 
sequence number of p, respectively. 


From the precondition of the rm-send,(p) action of RMy,;, it follows that 
u{|RM-CLIENT;].status = member and h = _ Sp. Invariant 5.16 implies that 
u[SRM-MEM,].status = member and, since (u,s) € R, it is the case that 
s|RM(oo)].status(h) = member. 
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We consider the effects of rm-send;(p) according to whether p is the foremost packet 
from h. First, consider the case where p is the foremost packet from h; that is, 
u[SRM-REC),].min-segno(s,) =. In this case, the rm-send;(p) action of RM; sets the 
expected set from h to the set suffiz(p), adds id(p) to the set of delivered packets from h, and 
records the transmission time of p. 


Since it is the case that u[SRM-REC,;].min-seqno(s,») =1L, Invariant 5.6 implies that 
u[SRM-REC),].expected(s,) = 0. Since (u,s) € R, it follows that s[RM(oo)].expected(h, h) = 0. 
Thus, the rm-send;(p) action of RMg(co) matches the effects of the rm-send;(p) action of 
RMy. It follows that (u’,s’) € R. 


Second, consider the case where p is not the foremost packet from h; that is, 
u[SRM-REC),].min-segno(s,) AL. In this case, Invariant 5.17 and the precondition of 
rm-send;(p) imply that i, = u[SRM-RECp].maz-seqno(sp) +1. Thus, the rm-send;,(p) action 
of RM; records the transmission time of p and adds id(p) to the set of delivered packets from 
h. 


Since it is the case that i, = u[SRM-RECp].maz-seqno(s,) + 1, Invariant 5.2 implies that 
u[SRM-REC),].min-seqno(sp) < ip. Thus, it follows that id(p) € u[SRM-REC,;].proper?(h). 
Since u[SRM-MEMa].status = member, Invariant 5.6 implies that u[SRM-RECp].expected(h) = 
u[SRM-REC;].proper?(h). Thus, it follows that id(p) € u[SRM-RECp].expected(h). Since 
(u,s) € R, it is the case that s[RM(oco)].expected(h,h) = u[SRM-REc,].expected(h). Thus, 
it follows that id(p) € s[RM(oo)].expected(h,h). Thus, the rm-send;,(p) action of RM¢(co) also 
records the transmission time of p and adds p to the set of delivered packets from h. Thus, it 
follows that (u’,s’) € R. 


rm-recv,(p), for any h € H and p € Pry-curnt: the corresponding execution fragment of 
RMs(co) is comprised solely of the rm-recv;(p) action. Let s, and i, denote the source and 
sequence number of p, respectively. 


We first show that the rm-recv;,(p) action of RMg(oc) is enabled in the state s. From the pre- 
condition of the rm-recvp(p) action of RMz, it follows that u[SRM-REC,].status = member 
and p € u[SRM-RECy;].to-be-delivered. Invariant 5.18 implies that u[SRM-MEM,].status = 
member and, since (u,s) € R, it follows s[RM(oo)].status(h) = member. Since p € 
u[SRM-REC)].to-be-delivered, Invariant 5.8 implies that h 4 source(p). Moreover, Invariant 5.20 
implies that p € u[SRM].sent-pkts. Since (u, s) € R, it follows that p € s[RM(co)].sent-pkts. 


We proceed by showing that s satisfies the last two terms in the precondition of rm-recv;(p) 
in RMsg(oo). Since the delivery delay parameter A is equal to co for the RMg(co) automaton, 
s[RM(oo)] trivially satisfies the term expected(h, 8») = 0 > now < trans-time(p) + A. 


Finally, we show that s[RM(co)| satisfies the term expected(h, s,) 4 0 = id(p) € expected(h, s,). 
Suppose that it is the case that s{[RM(oo)].expected(h,s,) # 0. Since (u,s) € R, it follows that 
u{[SRM-REC),].expected(s,») # 0. Thus, since p € u[SRM-RECa].to-be-delivered, Invariant 5.9 
implies that id(p) € u[SRM-REC)].expected(s,). Finally, since (u,s) € R, it follows that 
id(p) € s|RM(co)].expected(h, sp), as needed. 


The rm-recv;,(p) action of RM; sets the expected set of packets from s, to the set suffix(p), 
unless already non-empty, and adds p to the set of delivered packets from s,. The rm-recv,,(p) 
action of RM(co) matches precisely the effects of the rm-recvp;(p) action of RM;. Thus, it 
follows that (u’,s’) € R. 


v(t), for any t € R2°: the corresponding execution fragment of RMs(oo) is comprised solely of 
the v(t) action. Since the effects of the v(t) actions of the RM; and the RMs(co) automata 
are identical, it suffices to show that the v(t) action is enabled in s. Since the delivery delay 
parameter A is equal to co for the RM (co) automaton, the term now +t < trans-time(p) + A 
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of the precondition of the v(t) action of RMg(cc) is satisfied for all p € Pray-curnr- Thus, it 
follows that the v(t) action of RMg(oo) is enabled in s. 


Theorem 5.12 RM; < RMs(oo) 


Proof: Follows directly from Lemma 5.11. | 


5.4.5 Liveness Analysis 


In this section, we show that, under certain constraints, RM; implements RMsg(A), for any 
A€ R*°. 


Definitions 


Suppose p € Pram-curent, pkt € Pspm, and a is an admissible timed execution of RM, that contains 
the transmission of p; that is, a contains the action rm-senda(p), for h € H,h = source(p). For 
pkt € Pspm, we say that pkt pertains to p if type(pkt) € {DATA,RQST,REPL} and id(pkt) = id(p). 
We let Psrm[p] denote the elements of Pspm that pertain to p. 


We let the number of packet drops in a pertaining to p, denoted a.drops(p), be the number of packet 
drops suffered by packets pertaining to p; that is, a.drops(p) is the number of occurrences of an 
action mdrop(pkt’, Ha) in a, for pkt! € Prpycasr-Cumnr and Hg C H, such that strip(pkt') € Pgpw[p]. 


We let aexzecs,(RMz,), for k € Nt, be the set of admissible timed executions of RM; in which the 
number of packet drops suffered by the packets pertaining to the transmission and, potentially, the 
recovery of any packet p is at most k. That is, a € aexecs,(RM/;) iff a.drops(p') < k, for any packet 
p! © Pem-curnt transmitted in a. Finally, we let attraces;,(RM_,) be the traces of all executions of 
RM, in aexecs,(RM7). 


We let the transmission time of p in a, denoted a.trans-time(p), be the point in time in a at 
which p is transmitted; that is, the time of occurrence of rm-send;(p) in a. Since packets are 
transmitted by the clients of the reliable multicast service at most once (Lemma 4.2), it follows 
that the transmission time of any packet transmitted in any admissible timed execution of RM7 is 
well-defined and unique. 


Execution Constraints 


We proceed by defining several constraints on admissible executions of RM;. These constraints 
facilitate the statement of conditional claims regarding the timely transmission of packets for RM. 


Constraint 5.1 (No Crashes) Let a be any admissible timed execution of RM;. None of the 
hosts crash in a; that is, for any h € H, no crashp actions occur in a. 


Constraint 5.2 (No Leaves) Let a be any admissible timed execution of RM;. None of the hosts 
leave the reliable multicast group in a; that is, for any h © H, no rm-leavey,, actions occur in a. 


Let d,d € R2°, such that d > 0, d > 0, and d < d. The following constraint specifies the set of 
executions of RM; in which the transmission latency between any two hosts h,h’ € H,h 4h’ is 
bounded from below and above by d and d, respectively. 
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Constraint 5.3 (Bounded Inter-host Transmission Latencies) Let a be any admissible 
timed execution of RM; and h,h’ be any two distinct hosts in H. The transmission latency 
incurred by any packet multicast using the IP multicast service by h and received by h' in a lies 
in the interval [d, dj; that is, if p © Prpmcasr-Cumntr 28 @ packet multicast by h in a, then the time 
elapsing from the time of occurrence of the action msend;,(p) to that of any action mrecvp,(p) lies 


in the interval {d, d]. 


The following constraint specifies the set of executions of RM, in which the fate of any packet 
transmitted using the IP multicast service is resolved within d time units. 


Constraint 5.4 (Bounded Transmission Resolution) Let a be any admissible execution of 
RM, containing the discrete transition (u,7,u’), for u,u’ € states(RM;), h € H, p € 
Prpmecast-Cumnr, and m = msend;(p). Then, for all h’ € u[IPMCAST].members,h’ 4 h, either a 
crash,, rm-leave,, mrecvp/(p), or mdrop(p, Ha), for Ha C H, h’ © Ha, action occurs no later 
than d time units after the particular occurrence of the discrete transition (u,7m,u’) in a. 


The following constraint specifies the set of executions of RM; in which the inter-host distance 


estimates of any host always lie in the interval |[d,d]. The satisfaction of this constraint requires 


that DFLT-DIST € [d, d]. 


Constraint 5.5 (Bounded Inter-host Distance Estimates) Let a be any admissible timed 
execution of RM;. For any state u of RM; in a, the inter-host distance estimates of the 


recovery component of each reliable multicast process of RM, lie in the interval [d,d]; that is, 
u[SRM-REC)].dist(h’) € [d,d], for allh,h'€ H,h#h’. 


Letting DET-BOUND € R@°, such that d < DET-BOUND, the following constraint specifies the set of 
executions of RM, in which the delay in detecting packet losses is bounded by DET-BOUND. 


Constraint 5.6 (Bounded Detection Latency) Let a be any admissible timed execution of 
RM;. Let p € Pro-cumnr be any packet transmitted in a, id(p) = (Sp,ip), and h € H,h F Sp. 
Moreover, let u be any state of RM; in a such that a.trans-time(p) + DET-BOUND < u.now. 
Then, if id(p) € u[SRM-REC;].expected(sp), then either id(p) € u[SRM-RECa].delivered(s,) or 
id(p) € u[SRM-REc,].scheduled-rgqsts?. 


Let C-aexecs(RMz) be the set of all admissible timed executions of RM; in aexrecs(RMr) that 
satisfy Constraints 5.1, 5.2, 5.3, 5.4, 5.5, and 5.6. Let C-attraces(RM,) be the traces of all 
the executions of RM; in C-aexrecs(RMy). Let C-aerecs,(RMy), for k € N*, be the subset of 
aexecs,(RMy) comprised of all admissible timed executions of RM; that satisfy Constraints 5.1, 
5.2, 5.3, 5.4, 5.5, and 5.6; that is, for k € Nt, C-aexecs,(RM,) = aexecs;,(RM,)M C-aexecs(RM/7). 
Moreover, let C-attraces;,(RMz,) be the traces of all executions of RM; in C-aexecs;,(RM_). 


Execution Definitions 


Let a’ be any admissible timed execution in C-aerecs(RM,). We say that the host h detects the 
loss of p in a’ if it schedules a request for p € Prw-cuenr in a’. If the host h detects the loss of 
p in a’, then we let a’.det-time;(p) denote the point in time in a’ at which h detects the loss of 
p. We let a’.det-latency;,(p) denote the loss detection latency of p for h in a’; that is, the time 
elapsing from the time p is transmitted to the time the host h detects the loss of p in a’. We let 
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a’.rec-latencyn(p) denote the loss recovery latency of p for h in a’; that is, the time elapsing from 
the time the host h detects the loss of p to the time it receives p in a’. 


When a host h € H schedules a request for p € PrM-curnr With a back-off of k—1, for any k € Nt, 
we say that it initiates a k-th recovery round for p. Each recovery round (except the first) also 
initiates a back-off abstinence period. Any request for p received during this back-off abstinence 
period is discarded. If the packet p is received while a scheduled request for p by A is awaiting 
transmission, then the scheduled request is canceled. Once the back-off abstinence period expires, 
either the reception of a request for p or the transmission of the scheduled request for p by h 
initiates the k + 1-st recovery round for p at h. In this case, we define the k-th round request of h 
for p to be the request for p upon whose reception or transmission the host fA initiates the k + 1-st 
recovery round for p. Moreover, we define the completion time of the k-th recovery round for p of 
h to be the point in time at which h either receives p or initiates its k + 1-st recovery round for p. 


Suppose that a host h’ € H receives the k-th round request of h for p while it is a member of 
the reliable multicast group and after archiving the packet p. When h’ receives this request, either 
i) a reply for p is already scheduled, ii) a reply for p is already pending, or iii) a reply for p is 
neither scheduled, nor pending. In the case where a reply for p is already scheduled, h’s request 
for p is discarded. Moreover, the reply that is already scheduled at h’ is considered to be the reply 
pertaining to the k-th round request of h for p. In the case where a reply for p is already pending, 
h’s request for p is discarded. Moreover, the reply that is pending at h’ is considered to be the reply 
pertaining to the k-th round request of h for p. Finally, in the case where a reply for p is neither 
scheduled, nor pending, h’ schedules a reply for p. The reply that is either received or transmitted 
by h’ and that results in the cancellation of the reply scheduled by h’ for p is considered to be the 
reply to the k-th round request of h for p. 


Liveness Proof 


Lemma 5.13 Let a be any admissible timed execution of RM, that satisfies Constraint 5.3 
and contains the occurrence of a discrete transition (u,7,u’'), for u,u’ € states(RMz), h € H, 
p © Prpmcast-Curenr, and m = mrecvp(p). Then, any other mrecvy(p), for h’ © H,h' #h, ina 
occurs no earlier and no later than d—d time units from the particular occurrence of (u,7,u’) in 
Q. 


Proof: Let (v,7,v’), for v,v’ € states(RM,), h’ € H,h’ 4 h, p © Prpwcast-cumnt, and 
m7 = msendy/(p) be the discrete transition in a involving the transmission of p. Constraint 5.3 
implies that the time elapsing from the time of occurrence of the action msendj/(p) to that of any 


action mrecvp(p), for h” ¢ H,h" # h’ lies in the interval [d,d|. Thus, any two such actions are 
separated in time by at most d— d time units. | 


Definition 5.2 Let h © H, k € Nt, p © Prwecumnr, (8,7) = id(p), and a € C-aexrecs(RM7). 
We say that h either sends or receives its k-th round request for p and schedules its k + 1- 
st round request for p upon the occurrence of a discrete transition (u,7,u’) in a such that 
(s,i,t,k) € u[SRM-RECa].scheduled-rqsts and (s,i,t',k +1) € w'[SRM-REC,].scheduled-rqsts, for 
some t,t’ € R29. 


Lemma 5.14 Let k Ee Nt, k > 1, h © H, p © Pam-cumnt, and a € C-aerecs(RMy) such that a 
contains the transmission of p. Suppose that the host h schedules k-th and k+1-st round requests for 
the packet p ina. Let ty, tp41 € R=° be the points in time in a at which the host h schedules its k-th 
and k+1-st round requests for p, respectively. Then, it is the case that th44 < ty +2*-1(Cy+Co)d. 
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Proof: This follows from the fact that time in the SRM-REc, automaton is not allowed to elapse 
past the transmission time of any scheduled request. Constraint 5.5 implies that the k-th round 
request is scheduled for transmission no later than t, + 2*-!(C, + C2)d. Thus, if no request is 
received by A prior to the time at which its k-th round request for p is scheduled for transmission, 
then h transmits its k-th round request. Thus, h either sends or receives its k-th round request for 
p no later than tz + 2*-1(C, + C)d, as required. | 


Corollary 5.15 Letk EN*,h € H, p © Pryecurnr, and a € C-aexecs(RMy7) such that a contains 
the transmission of p. Suppose that the host h schedules k-th and k + 1-st round requests for the 
packet p in a. Let th, € R=° be the point in time in a at which the host h either sends or receives 
its k-th round request for p and schedules its k + 1-st round request for p. Then, it is the case that 
thoi < a.det-time;(p) + (2* — 1)(C, + Co)d. 


Proof: Follows from Lemma 5.14 and the fact that h detects the loss of p at the point in time 
when it first schedules a request for p. According to the SRM-REC, automaton, the first request 
scheduled for a packet is either a 1-st or 2-nd round request for the given packet. | 


Lemma 5.16 Let k Ee Nt, k > 1, h © H, p © Payecuenr, and a € C-aexecs(RMy) such that a 
contains the transmission of p. Suppose that the host h schedules k-th and k + 1-st round requests 
for the packet p in a. Let ty, th41 € R=° be the points in time in a at which the host h schedules its 
k-th and k +1-st round requests for p, respectively. Then, it is the case that ty, + 2*-1C3d < ty41. 


Proof: Constraint 5.5 implies that the k-th round back-off abstinence period expires no earlier 
than 2*-!Csd time units past tz; that is, no earlier than tz + 2*~!C3d in a. From Assumption 5.1, 
it is the case that C3 < C ,. Thus, the k-th round request is scheduled for transmission at a point 
in time that succeeds ty + 2*~!Cd in a. 


The host h schedules its k + 1-st round request for p when it either sends or receives its k-th 
round request for p; that is, upon the occurrence of either a send-rqst,(s,i) action, such that 
(s,t) = id(p), or a process-mpkt,(pkt) action, for pkt € Pgrm, such that id(pkt) = id(p) 
and type(pkt) = RQST. In the case of a send-rqst;(s,7) action, Invariant 5.15 implies that if 
the send-rqst,(s,7) action is enabled, then a request for p is not pending. In the case of a 
process-mpkt,,(pkt) action, the effects of the action process-mpkt,(pkt) imply that the k-th round 
request for p is backed-off only while a request for p is not pending. 


It follows that the point in time at which the host h either sends or receives its k-th round request 
for p succeeds the expiration time of the back-off abstinence period of the k-th round request of h 
for p; that is, ty + 2°-1C3d < tpy1. |_| 


Lemma 5.17 Leth,h’ © H,h 4h’, p © Pam-cumnr, and a € C-aexecs(RM_,) such that a contains 
the transmission of p. Suppose that h’ receives a request for p from h at time t! € R2° ina. Suppose 
that when h' receives this request, it is a member of the reliable multicast group and has already 
archived p. Then, the reply of h’ pertaining to the particular request of h for p is either sent or 
received by h' no later than t! + (Di + Dg)d in a. 

Proof: Constraint 5.5 implies a reply is scheduled for transmission no later than (D , + D2)d 
time units past its scheduling time. When h’ receives the request of h for p, a reply for p is either 
already scheduled, already pending, or neither scheduled nor pending. We consider each of these 
scenarios separately. First, if a reply for p is already scheduled, its transmission time is no later 
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than t/+(D ,+ D2)din a. Thus, if either an original transmission or a reply for p is not received by 
h’ by the scheduled transmission time of its own reply, then the host h’ transmits its own reply. It 
follows that the reply of h’ pertaining to the particular request of h for p is either sent or received 
by h’ no later than the point in time ¢/ + (D; + D2)d in a. Second, if a reply for p is already 
pending, then the reply of h’ pertaining to the particular request of h for p has already been either 
sent or received; that is, the reply of h’ pertaining to the particular request of h for p is either 
sent or received by h’ no later than ¢’. Finally, if a reply for p is neither scheduled nor pending, 
then the reply of h’ pertaining to the particular request for p from h is scheduled for no later than 
t! + (D,+ D2)d. In either scenario, the reply of h’ pertaining to the particular request of h for p is 
either sent or received by h’ no later than t/ + (D; + Do2)d ina. |_| 


Lemma 5.18 Leth,h’ © H,h 4h’, p © Pam-cusnr, and a € C-aexecs(RM_,) such that a contains 
the transmission of p. Suppose that h’ receives a request for p from h at time t! € R2° ina. Suppose 
that when h' receives this request, it is a member of the reliable multicast group and has already 
archived p. Then, the reply abstinence period of the reply of h’ pertaining to the particular request 
of h for p expires no later than t! + (D, + D2 + D3)d in a. 


Proof: Constraint 5.5 implies that the reply abstinence period of any reply expires no later than 
(D, + D2 + D3)d time units past its scheduling time. The rest of the proof is analogous to the 
proof of Lemma 5.17. | 


Lemma 5.19 Letk € Nt, h,h’ € H,h Fh’, p © Pruecumnt, and a € C-aexecs(RMz) such that a 
contains the transmission of p. Suppose that the host h schedules k-th and k + 1-st round requests 
for the packet p in a. Suppose that the host h' receives the k-th round request of h for p. Let 
thai € R=° be the point in time in a at which the host h either sends or receives its k-th round 
request for p and schedules its k+1-st round request for p. Then, the host h' receives the k-th round 
request of h for p no later than ty41 +d ina. 


Proof: The host h either sends or receives its k-th round request for p and schedules its k + 1-st 
round request for p upon the occurrence of either a send-rqst;,(s,7) or a process-mpkt,, (pkt) 
action, where id(pkt) = id(p) and type(pkt) = RQST. We consider there two cases separately. 


First, in the case of a send-rqstp(s,i) action, Constraints 5.1 and 5.2 and Lemmas 5.6 and 5.8 
imply that the send-rqstp(s,7) action is instantaneously followed by a msend,(pkt’) action, for 
pkt! © Prpmcast-Curent, such that id(strip(pkt’)) = id(p) and type(strip(pkt’)) = RQST. Furthermore, 
Constraint 5.3 implies that h’ receives this request within at most d time units. 


Second, in the case of a process-mpktp(pkt) action, a mrecvp(pkt’) action, for 
pkt' © Prpucast-Cunr; Such that pkt = strip(pkt’), instantaneously precedes process-mpkt;(pkt). 
Lemma 5.13 implies that h’ receives this request within at most d—d time units. | 


Lemma 5.20 Let a be any admissible timed execution of RM, that contains the transmission 
of a packet p € Pro-cunmnr. For any state u € states(RM7) in a, if u.trans-time(p) AL, then 
u.trans-time(p) = a.trans-time(p). 


Proof: The only action that sets the variable trans-time(p) is the action rm-send,(p), for h = 
source(p). By Lemma 4.2, the action rm-send,(p) occurs only once in a. Let (v,rm-send;(p), v’) be 
the discrete transition in a involving the action rm-send;(p). By the definition of a.trans-time(p), 
it follows that a.trans-time(p) = v.now. The action rm-send;,(p) sets the variable trans-time(p) to 
the value of now. It follows that v’.trans-time(p) = a.trans-time(p). 
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Since the action rm-send,;(p) occurs in a only once, it follows that for any v_,v; € a, such 
that v- <q v and vw’ <q v4, it is the case that v_.trans-time(p) = 1 and v4.trans-time(p) = 
u’.trans-time(p). Since v’.trans-time(p) = a.trans-time(p), it follows that vz.trans-time(p) = 
a.trans-time(p). a 


Lemma 5.21 Let h,h’ € H, a € aerecs(RMz), u,u’ € states(RMz) be any states in a, such 
that u <q u’, and Qyy be the finite execution fragment of a starting in u and ending in u’. If 
u[SRM-REC)].expected(h') 4 0 and ay, contains neither crash, nor rm-leave, actions, then it 
is the case that u[SRM-RECp].expected(h’) = u'[SRM-REC;].expected(h’). 


Proof: The proof is by induction on the length n € N of ay. For the base case, consider 
a finite execution fragment a,,,, of length n = 0. Since u = uw’, it trivially follows that 
u|[SRM-REC)].expected(h’) = u'[SRM-RECa].expected(h’). 


For the inductive step, consider an execution fragment a, of length n = k+1. Let a,x be the prefix 
of Ay, involving the first k steps and uz = a,x.lstate. Suppose that u[SRM-RECp].expected(h’) 4 0 
and Qyy contains neither crash, nor rm-leave,, actions. The induction hypothesis implies that 
u|[SRM-REC)].expected(h') = uz[SRM-REC)].expected(h’). 


Now, consider the step from uz to u’. The only actions of SRM-REC, that may affect the variable 
SRM-REC),.expected(h’) are the actions crashp, rm-leave;,, rm-send,(p), and rm-recv;,(p), for p € 
PrM-Curnt- Quu Contains neither crash, nor rm-leave,, actions. The action rm-send;,,(p) affects 
the variable SRM-RECp.expected(h’) only when h’ = h = source(p) and SRM-RECpj.expected(h’) = 
0. The action rm-recva(p) affects the variable SRM-REC);,.erpected(h') only when h’ = source(p) 
and SRM-RECpj.expected(h’) = @. Since u[SRM-RECc;].exrpected(h') 4 0, the step from uz to 
u’ does not affect the variable SRM-REC),.expected(h’); that is, uz[SRM-RECa].expected(h’) = 
u'[SRM-RECa].erpected(h’). Since u[SRM-REC)].expected(h’) = uzx[SRM-RECp].expected(h’), it 
follows that u{SRM-REC)].erpected(h') = u'[SRM-RECa].expected(h’). a 


Lemma 5.22 Let h,h’ © H, a € aexecs(RMz), u,u’ € states(RM,) be any states in a, such that 
U <q u’, and Ayy be the execution fragment of a starting in u and ending in u'. If ayy contains 
neither crash, nor rm-leavep, actions, then it is the case that u[SRM-RECa].expected(h’) C 
u'[SRM-RECp].expected(h’). 


Proof: Suppose that a,,” contains neither crash; nor rm-leave, actions. If it is the case 
that u[SRM-REC;].expected(h’) = 0, then it trivially follows that u[SRM-RECp].expected(h’) C 
u'[SRM-RECa].expected(h’). Otherwise, if u[SRM-RECa].expected(h’) 4 @, then Lemma 5.21 
implies that u[SRM-REC;].expected(h’) =  u'[SRM-REC)].expected(h’). It follows that 
u[SRM-REC),].expected(h') C u'[SRM-REC;].expected(h’). 


Lemma 5.23 Let h,h’ © H, a € aexecs(RM/7), u,u’ € states(RM_) be any states in a, such that 
U <q u’, and Ay, be the finite execution fragment of a starting in u and ending in u'. If Qyy con- 


tains neither crash; nor rm-leave;, actions, then it is the case that u[SRM-RECa].delivered(h’) C 
u'[SRM-RECa].delivered(h’). 


Proof: Follows by induction on the length n € N of the finite execution fragment a,,,,, after 
recognizing that all actions, except crash; and rm-leave;, may only add elements to the variable 
SRM-REC),.delivered(h’). a 
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Lemma 5.24 Let k € Nt, p © Pry-cuent, and a be any admissible timed execution of RM; in 
C-aexecs,(RM,) that contains the transmission of p. Moreover, let hh € H and u be any state of 
RM, in a such that a.trans-time(p) + d < u.now and id(p) € u[SRM-REC)].erpected(source(p)). 
For any state u! € states(RMy) in @ such that a.trans-time(p) +d < u'.now and ul <q u, it is the 
case that id(p) € u'[SRM-RECa].expected(source(p)). 


Proof: Let id(p) = (8p,%p) and p’ € PrM-cumnr, such that id(p’) = (sp, 7’), be the earliest packet 
expected from s, by h in the state u; that is, id(p’) € u[SRM-RECa].expected(s,) and for all 
(Sp, i) € u[SRM-REC,].expected(s,) it is the case that i! < i”. Thus, it follows that i’ < i. 


The variable SRM-REC;.ezpected(s,) is set in @ upon either the transmission (when h = sp) 
or the reception (when h # s,) of p’. Let v € states(RMy,) be the state following either the 
transmission or the reception of p’ by h in a, respectively. By definition of v, it is the case 
that v[SRM-REC;].expected(s,) # @. Since a contains neither crash, nor rm-leave; actions 
(Constraints 5.1 and 5.2), Lemma 5.21 implies that for any v’ € states(RMy) in a, such that 
VU <q V’, it is the case that v[SRM-REC;].expected(s,) = v'[SRM-REC;].expected(sp). 

Constraint 5.3 implies that v.now < a.trans-time(p’) + d. Moreover, Lemma 4.3 implies that 
a.trans-time(p') < a.trans-time(p). Since a.trans-time(p) + d < u'.now, it follows that v.now < 
u'.now. Since v.now < u’.now, it follows that v <q wu’. Thus, since v <q wu’, u’ <q u, 
and v[SRM-RECa].expected(s,) # 9, Lemma 5.21 implies that v[SRM-REC;].expected(sp) = 
u'[SRM-RECp].expected(s,) and v[SRM-RECp].expected(s,) = u[SRM-REC)].expected(sp). Thus, 
it is the case that u’[SRM-REC;].ezpected(s,) = u[SRM-RECp].expected(s,). Since id(p) € 
u[SRM-REC,,].expected(s,), it follows that id(p) € u'[SRM-RECa;].expected(s,). a 


Let k* = [log,[(D, + D2 + D3 + 2)d — d] — logs(C3d)]. The following lemma states that, under 
Constraints 5.1, 5.2, 5.3, 5.4, 5.5, and 5.6, k* is the number of requests that must be scheduled 
before the request scheduling delays become large enough to ensure that one round’s replies do not 
interfere with the next round’s requests. 


Lemma 5.25 Let k € Nt,k > k*, p © Panecumnt, h,h’ © Hyh #h’, and a € C-aerecs,(RM/7), 
such that a contains the transmission of p. 


Let u € states(RM,) be any state in a, such that id(p) € u[SRM-RECp].expected(source(p)) and 
id(p) ¢ u[SRM-RECa].scheduled-rqsts?, following which h schedules a k + 2-nd round request for p. 


Let u’ € states(RM,) be any state in a, such that id(p) € u/[SRM-RECp’].delivered(source(p)), 
following which h’ receives the k-th and k + 1-st round requests of h for p. 


The replies of h' to the k-th and k + 1-st round requests of h for p are distinct. 


Proof: It suffices to show that the reply abstinence period pertaining to h’’s reply to the k-th 
round request of h for p expires prior to the time at which h’ receives the k + 1-st round request of 
h for p. 


Let tp, th41 € R2° be the points in time in a at which h schedules its k-th and k + 1-st round 
requests for p. From Lemma 5.19, h’ receives the k-th round request of h for p no later than 
tr41 +d. From Lemma 5.18, the abstinence period of the reply of h to the k-th round request of h 
for p expires no later than thi, +d + (D1 + Do + Ds)d. 


From Lemma 5.16, h either receives or transmits its k + 1-st round request after the point 
in time ty4, + 2*C3d. From Lemma. 5.13, h’ receives such a request after the point in time 
teoi + Cad _ d+ d. Since k* = [logs[(D1 + Dog + Ds 4 2)d d| logs(C3d) | and k > k*, it 
follows that t,4, +d+(D, + Do + D3)d < ty4, + 2*C3d—d+d. 
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Recall that h’ receives the k+1-st round request of h for p after the point in time t,,1+2*C3d—d+d. 
Since thy, + d+ (Di + Do + D3)d < thy, + 2*C3d — d+ d, it follows that h’ receives the k + 1-st 
round request of h for p after the expiration of the abstinence period of the reply of h’ to the k-th 
round request of h for p. It follows that the replies of h’ to the k-th and k + 1-st round requests of 
h for p are distinct. | 


Let REC-BOUND(k) = [(2* — 1)(C, + C2) + D1 + Do 4+ 2]d, for k € N+. The following lemma states 
that, for k € N*, the recovery of any packet in an admissible execution a € C-aexecs;,(RM/;) 
involves at most k* + k recovery rounds. Following the k*-th recovery round, one round’s replies 
do not interfere with the next round’s requests. Thus, all recovery rounds that follow the first k* 
recovery rounds may fail only due to packet drops. Since the number of packet drops pertaining 
to the recovery of any packet in @ is at most k, it follows that at most k* + k recovery rounds are 
needed to recover any packet in a. 


Lemma 5.26 Let k € N*, a € C-aexecs;,(RM,), and u,u’ € states(RMy) be any states in 
a such that u.now + REC-BOUND(k* +k) < u’.now. For any h € H and p © Prau-curnt, if 
id(p) € u[SRM-REC,,].scheduled-rgsts?, then id(p) € u'[SRM-RECa].delivered(source(p)). 


Proof: Since a € C-aexecs;,(RMy), Constraints 5.1 and 5.2 imply that the source s, of p neither 
crashes nor leaves the reliable multicast group following the transmission of p. Thus, it is capable 
of replying to any of the retransmission requests for p sent in a. 


Suppose that id(p) € u[SRM-RECp].scheduled-rgqsts? and let v € states(RM,) be the first state in 
a such that id(p) € v[SRM-REC)].scheduled-rqsts? and v' € states(RMry) be the first state in a 
such that v.now + REC-BOUND(k* +k) < v’.now. By definition, it follows that v <q uand v' <q wu’. 


Since a € C-aexecs,(RM/;), it contains at most k packet drops pertaining to the transmission and 
recovery of p. The loss of the original transmission of the packet p accounts for at least one such 
packet drop. Thus, at most k — 1 packet drops may occur during the recovery p. Lemmas 5.4 
and 5.5 imply that following the state v in a, the host h continues initiating recovery rounds for p 
until p is recovered. We proceed by showing that the host h recovers p by the completion time of 
its k* + k recovery round for p. 


Consider the interaction of s, and h pertaining to h’s recovery of p. From Lemma 5.25, the replies 
of s, to the requests of the recovery rounds of h following the k*-th round of h are distinct. Thus, 
each recovery round following the k*-th recovery round may fail either due to the loss of the request 
or the loss of the reply of the given round; that is, each recovery round following the k*-th recovery 
round that fails accounts for at least one packet drop. It follows that at most k* +k recovery rounds 
are required for h to successfully recover p. 


Corollary 5.15, Lemma 5.17, and Constraint 5.3 imply that h completes its k* + k recovery rounds 
no later than REC-BOUND(k* + k) time units past the point in time at which it schedules its first 
request for p. Since v is the first state in a such that id(p) € v[SRM-REC;].scheduled-rqsts? and 
v.now + REC-BOUND(k* + k) < v’.now, it follows that h receives p prior to v’ in a. Lemma 5.23 
implies that id(p) € v'[SRM-REC)].delivered(s,). 


Since uv’ <q wu’ and id(p) € v'[SRM-RECp].delivered(s,), Lemma 5.23 implies that id(p) € 
u'[SRM-RECp].delivered(s,). a 


Lemma 5.27 Let k ¢ N+, A = DET-BOUND + REC-BOUND(k* + k), p © Prmecurnr, a be any 
admissible timed execution of RM; in C-aexecs;,(RMy) that contains the transmission of p, and 
u € states(RMy,) be any state in a such that a.trans-time(p) + A < u.now. For any h € H, if 
h € u.intended(p), then it is the case that h € u.completed(p). 
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Proof: Let s, = source(p) and suppose that h € u.intended(p). Since h € u.intended(p), it follows 
that id(p) € u[SRM-RECa;].expected(s,). Let u’ € states(RM_) be the earliest state in a such that 
a.trans-time(p) +DET-BOUND < u!.now. Since d < DET-BOUND, it follows that a.trans-time(p)+d < 
u'.now. Since id(p) € u[SRM-REC,].expected(s,), a.trans-time(p) +d < ul.now, and u! <q u, 
Lemma 5.24 implies that id(p) € u’/[SRM-REC;].expected(sp). Constraint 5.6 implies that either 
id(p) € w[SRM-RECp].delivered(s,) or id(p) € u'[SRM-REC)].scheduled-rgsts? . 


First, consider the case where id(p) € u/[SRM-RECp].delivered(s,). Since either u! <q u and 
id(p) € w'[SRM-RECp].delivered(s,), Lemma 5.23 implies that id(p) € u[SRM-REC)].delivered(s,). 
It follows that h € u.completed(p). 


Second, consider the case where id(p) € u’[SRM-REC,].scheduled-rgsts?. Let (u’_,7,u’) be the 
discrete transition in a leading to the particular occurrence of u’. Since, u’ is the earliest state in 
a such that a.trans-time(p) + DET-BOUND < u’.now, it follows that 7 is a non-stuttering time- 
passage action, u!_.now < u’.now, and u!_.now < a.trans-time(p) + DET-BOUND. Since time- 
passage actions do not affect the derived variable SRM-RECp.scheduled-rqsts?, it follows that 
id(p) € u'_[SRM-RECc)].scheduled-rgsts?. Since u'_.now < a.trans-time(p) + DET-BOUND and 
a.trans-time(p) + A < u.now, it follows that u/_.now + REC-BOUND(k* + k) < u.now. 


Since u/_.now + REC-BOUND(k* + k) < u.now and id(p) € ul_[SRM-RECa].scheduled-rgsts?, 
Lemma 5.26 implies that id(p) € u[SRM-REC)].delivered(sp); that is, h € u.completed(p). a 


We conclude by showing that any timed trace of RM, in the set C-attraces;,(RM_) is also a timed 
trace of the specification automaton RM (A), for A = DET-BOUND+-REC-BOUND(k* +k). Thus, given 
Constraints 5.1, 5.2, 5.3, 5.4, 5.5, and 5.6 and assuming that the number of packet drops pertaining 
to the transmission and, potentially, the recovery of any packet is bounded, RM; implements the 
timely reliable multicast service specification RM (A). 


The proof of this claim involves showing that the relation R of Definition 5.1 is a timed forward 
simulation relation from RM; to RMg(A), under the aforementioned constraints and assumptions. 
The key part of the proof involves showing the correspondence of the time-passage steps. In 
particular, we show that active packets are delivered to all the hosts is their intended delivery sets 
within A time units. 


Theorem 5.28 Let k € N* and A = DET-BOUND + REC-BOUND(k* +k). Then, it is the case that 
C-attraces;,(RM,) C attraces(RM3s(A)). 


Proof: It suffices to show that the relation R of Definition 5.1 is a timed forward simulation 
relation from RM; to RM5(A), for any execution in the set C-attraces;,(RMz). 


The proof that R is indeed a timed forward simulation relation is identical to that of Lemma 5.11 
with the exception that in this case showing the correspondence of the time passage transitions is 
nontrivial. 


Consider any discrete transition (u,7,u’) € trans(RM,), where 7 = v(t), for some t € R7°, that 
occurs in any admissible execution of RM, in the set C-attraces;,(RM,). It suffices to show that, 
for any reachable state s of RM 5(A) such that (u, s) € R, there exists a timed execution fragment 
a of RMs(A) such that a.fstate = s, a.lstate = s’, ttrace(a) = ttrace(uru’), the total amount of 
time-passage in @ is the same as the total amount of time-passage in uu’, and (u’,s’) € R. 

Let s be any reachable state of RMgs(A) such that (u,s) € R. The timed execution fragment 
of RMg(A) corresponding to the step (u,7,u’) is comprised solely of the v(t) action. We must 
show that the v(t) action is enabled in s; that is, we must show that, for any active packet 
p € s.active-pkts, it is the case that either s.now +t < s.trans-time(p) + A or s.intended(p) C 
s.completed(p). Since (u, s) € R, it suffices to show that, for any active packet p € u.active-pkts, it 
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is the case that either u.now +t < u.trans-time(p) + A or u.intended(p) C u.completed(p). 


Consider any active packet p € u.active-pkts. It suffices to show that if u.trans-time(p) + A < 
u.now +t, then u.intended(p) C u.completed(p). Let h € H be any host in u.intended(p). Since 
the action v(t) of RM; does not affect the derived history variable SRM.intended(p), it follows 
that h € u’.intended(p). Moreover, since u.trans-time(p) + A < u.now +t and the action v(t) 
increments the now variable by t time units, it follows that u.trans-time(p) + A < u'.now. Since 
A = DET-BOUND + REC-BOUND(k* + k), u.trans-time(p) + A < u’.now, and h € u’.intended(p), 
Lemmas 5.20 and 5.27 imply that h € u’.completed(p). Since the action v(t) of RM; does not 
affect the derived history variable SRM.completed(p), it follows that h € u.completed(p). |_| 


6 Contributions & Future Work 


The contributions of this paper are several. First, we present a timed I/O automaton model of the 
reliable multicast service. This model formally specifies the behavior of several reliable multicast 
protocols that strive to provide eventual delivery with, possibly, some timeliness guarantees. In 
particular, it dictates what it means to be a member of a reliable multicast group and which packets 
are guaranteed delivery to which members of the reliable multicast group. Moreover, we present a 
timed I/O automaton model of the SRM protocol. This model decomposes the functionality of the 
reliable multicast service, thus facilitating reasoning and the future modeling of either variations 
and extensions to SRM’s recovery scheme, or other reliable multicast protocols altogether. We 
show that our model of SRM is safe, in the sense that it may only deliver appropriate packets to 
each member of the reliable multicast group. We also show that, under certain constraints, our 
implementation is live, in the sense that it guarantees the timely delivery of the appropriate packets 
to each member of the reliable multicast group. 


In the future, we intend to relax the constraints used in our liveness analysis of SRM and to analyze 
the performance of SRM in the context of a dynamic group membership. We also intend to model, 
analyze, and compare the performance of extensions to SRM and other reliable multicast protocols. 
The safety analysis of each such protocol will guarantee that the protocols are compared on an equal 
footing; something rarely done precisely when comparing protocols. 
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